DEV Community: Juma

The Hidden Side of Bitcoin

Juma — Sat, 20 Jun 2026 11:39:18 +0000

The Code Most People Never See

Yeah,yeah i know more than 90% of the people reading this have heard of bitcoin. Everyone talks about Bitcoin's price. Few people talk about what makes it actually work. Under the hood, Bitcoin is a marvel of applied cryptography, distributed systems, and elegant scripting and you don't need to be a cryptographer to understand it.

01 Transactions
How a transaction is born
When you send Bitcoin, your wallet doesn't move coins the way a bank does. Instead, it constructs a raw transaction, a small blob of binary data referencing previous unspent outputs (UTXOs) as inputs, and specifying new outputs for the recipient and change.

That transaction is then broadcast to the peer-to-peer network using Bitcoin's gossip protocol. Every node that receives it validates the transaction independently, then forwards it to its peers, no central server involved.

# Ask your local node what chain it's on
bitcoin-cli getblockchaininfo

# Create a fresh receiving address
bitcoin-cli getnewaddress "savings"

# Send 0.001 BTC to an address
bitcoin-cli sendtoaddress "bc1q..." 0.001

02 Validation
What nodes actually check
What nodes actually check
Every full node runs the same checklist before accepting a transaction into its mempool:

Does each referenced UTXO exist and is it unspent?
Do inputs sum to at least as much as outputs (accounting for the fee)? much as outputs (accounting for the fee)?
Is the cryptographic signature valid for each input?
Does the unlocking script satisfy the locking script on the UTXO?

No trusted third party decides. The rules are in the code, and every node enforces them equally.

03 Cryptography
The signature that proves ownership
Bitcoin uses secp256k1 elliptic-curve cryptography. Your private key is a 256-bit secret number. Your public key and ultimately your address is derived from it mathematically, but the reverse is computationally infeasible.

To spend a UTXO, you prove you know the private key by producing a digital signature over the transaction data. The network verifies the signature using only your public key, your secret never leaves your wallet.

This is why "not your keys, not your coins" is more than a slogan. Without the private key, the signature cannot be produced and the output cannot be spent.

04 Mining
How blocks get added
Miners collect pending transactions from the mempool, assemble them into a block candidate, and then compete to find a special number the nonce such that the block's SHA-256 hash starts with enough leading zeros to meet the current difficulty target.

# The block header includes:
{
  "previousblockhash": "00000000000...",
  "merkleroot":       "e3b0c44298fc...",
  "nonce":            2083236893,
  "bits":             "1d00ffff"
}

Finding a valid nonce requires trillions of hash attempts. But verifying it takes milliseconds that asymmetry is the entire security model of Proof of Work. Once a block is found, it's broadcast and every other node verifies it instantly, then appends it to their chain.

05 Script
Bitcoin's tiny programming language
Every transaction output carries a scriptPubKey a small program in Bitcoin Script that defines the conditions for spending. The most common is Pay-to-Public-Key-Hash (P2PKH):

# Locking script (on the UTXO)
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

# Unlocking script (provided by the spender)
<signature> <pubKey>

Bitcoin Script is stack-based and intentionally limited no loops, no Turing-completeness. That restraint is a deliberate security choice. More advanced scripts power multisig wallets (requiring M-of-N keys), time-locks, and Lightning Network payment channels. Script is why Bitcoin is programmable money at the protocol level, not just a ledger.

This is for developers, not just traders
Understanding Bitcoin at the code level changes how you see the whole system. Transaction malleability, replace-by-fee, SegWit's witness data separation, Taproot's Schnorr signatures these aren't trivia. They're design decisions you'll encounter the moment you build anything on top of Bitcoin, whether that's a payment processor, a custody solution, or a Layer-2 protocol.

Running your own node also makes you a first-class participant in the network. You validate every block yourself. You don't trust anyone else's view of the chain.

What is docker

Juma — Sat, 20 Jun 2026 11:36:30 +0000

Docker for Beginners: The Magic Shipping Container

The Problem with Moving Day

Imagine you've spent weeks setting up your perfect home office. You've got your desk lamp at exactly the right angle, your keyboard at the perfect tilt, your three monitors arranged just so, and your 47 browser tabs open in a very specific order. Life is good.

Then your company says: "We need you to work from the office now."

You show up. There's a chair. Maybe a table. Nothing works the same way. Your muscle memory is confused. Your productivity crashes.

That is exactly what happens to a developer's app when it moves from their laptop to a server, or from one developer's machine to another's. And Docker is the solution that says: "What if you could just... bring the entire room?"

What Even Is Docker?

Docker is an open-source tool that lets you package your application and everything it needs to run, the code, the runtime, the libraries, the config files into a single, portable unit called a container.

Think of it like a magical lunchbox. You pack your ugali, sukuma wiki, and nyama choma in it at home. You open it at work, and everything is exactly as you left it. No one swapped your food. The portion sizes haven't changed. The container traveled with your meal intact.

Docker containers work the same way: your app travels fully packed, ready to run anywhere Docker is installed your laptop, your colleague's Linux machine, a cloud server in Frankfurt, or a Raspberry Pi sitting on someone's desk in Kisumu.

The "It Works on My Machine" Problem

Here's a developer horror story you'll encounter before you're very far into your career:

You build something beautiful on your machine. You push the code to GitHub. Your colleague pulls it, runs it, and immediately messages you:

"This doesn't work."

You stare at your screen. It works perfectly for you. You both have Node.js installed but you have version 18 and they have version 16. You have a library at version 2.3 and they have 2.1. Their operating system handles file paths differently. Somewhere in this maze of tiny differences, your app has quietly fallen apart.

This is so common it has a name: the famous "it works on my machine" problem. It's one of the most frustrating experiences in software development, and it's responsible for countless late nights, broken friendships, and passive-aggressive Slack messages.

Docker solves this by making your machine the environment, not just the code part of what gets shared. Everyone runs the exact same container. No surprises.

Containers vs. Virtual Machines: What's the Difference?

You might be thinking: "Wait, doesn't a Virtual Machine (VM) already do this?" And you're right to ask!

A Virtual Machine is like renting an entire apartment. You get your own operating system, your own virtual hardware, all completely isolated. It's powerful, but it's heavy a VM can take gigabytes of space and minutes to start.

A Docker container is more like renting a single furnished room in a co-living space. You share the building's plumbing and electricity (the host OS kernel), but your room is completely yours your files, your processes, your environment. Containers are lightweight, start in seconds, and use far fewer resources.

In short: VMs virtualize hardware, containers virtualize the operating system environment. Both isolate your app, but containers do it with much less overhead.

Key Docker Concepts (No Jargon Allowed)

Images

A Docker image is the blueprint a snapshot of your app and its environment, frozen in time. It's read-only. Think of it as a recipe: it tells Docker exactly what ingredients to use and how to set everything up.

Containers

A container is a running instance of an image. It's the meal you made from the recipe. You can run multiple containers from the same image, and they'll all behave the same way. If something breaks in one container, you just throw it away and start a new one. Mess gone.

Docker Hub

Docker Hub is like GitHub, but for Docker images. It's a public registry where developers share images. Need Nginx? Redis? PostgreSQL? Someone has already built and published a ready-to-use image. You just pull it down and run it.

Dockerfile

A Dockerfile is a plain text file where you write instructions for building your own custom image. It's basically saying: "Start with this base image, install these things, copy my code in, and run this command." Docker reads it and bakes your image for you.

Volumes

Volumes let you persist data outside of a container. By default, when a container is deleted, its data disappears too which is great for stateless apps but terrible for databases. Volumes are Docker's way of saying: "Save this data somewhere safe, even if the container dies."

Your First Docker Commands

Let's get hands-on. Here are a few commands every Docker beginner should know:

Pull an image from Docker Hub:

docker pull nginx

This downloads the official Nginx web server image to your machine.

Run a container:

docker run -d -p 8080:80 nginx

This starts an Nginx container in the background (-d) and maps port 8080 on your machine to port 80 inside the container (-p 8080:80).

See what's running:

docker ps

Lists all currently running containers like a task manager for Docker.

Stop a container:

docker stop <container_id>

Gracefully shuts down a running container. Find the container ID from docker ps.

Hands-On: Run a Web Server in 60 Seconds

Let's actually do something cool. Make sure Docker is installed on your machine, then open your terminal and type:

docker run -d -p 8080:80 --name my-first-server nginx

That's it. Now open your browser and go to http://localhost:8080.

You should see the Nginx welcome page, a web server running inside a Docker container, on your machine, that you launched with one command. No installation of Nginx. No configuration. No fighting with package managers.

When you're done playing with it:

docker stop my-first-server
docker rm my-first-server

That cleans up the container entirely. Like it was never there.

Why Should You Care About Docker?

As a developer, Docker means you stop wasting time debugging environment issues and spend more time building. You can spin up databases, message queues, and APIs locally with single commands.

As a DevOps engineer, Docker is the language of modern deployment pipelines. Containers slot neatly into CI/CD workflows, make scaling easier, and work beautifully with cloud providers.

As a Bitcoin or open-source contributor, Docker is how many projects distribute development environments. Want to run a Bitcoin node, a Lightning node, or contribute to a complex open-source project? Chances are there's already a Dockerfile waiting for you. You pull, you run, you contribute no three-hour setup battle required.

Docker is also the foundation of the modern cloud. Understanding it makes you literate in the language that practically every serious production system speaks today.

What's Next?

Now that you have the basics, here's where the rabbit hole leads:

Docker Compose A tool for defining and running multi-container apps. Instead of starting five containers manually, you write one docker-compose.yml file and bring everything up with docker compose up. Perfect for apps that need a web server, a database, and a cache all running together.

Docker Networking How containers talk to each other. Once your apps are split across multiple containers, you'll need them to communicate.

Kubernetes (K8s) The big boss of container orchestration. When you have hundreds of containers running across dozens of servers, Kubernetes manages them all — scaling up when traffic spikes, restarting crashed containers, and distributing load. It's Docker's best friend at scale.

Container Registries Beyond Docker Hub, you'll encounter private registries like AWS ECR, Google Artifact Registry, and GitHub Container Registry for storing your own custom images.

Start simple: install Docker, run a few containers, and write your first Dockerfile. The concepts will click fast, and suddenly a huge chunk of modern infrastructure will start making sense.

Welcome to the shipping business.

Happy containerizing and remember, if it works in Docker, it works everywhere.

Introduction to Git

Juma — Tue, 02 Jun 2026 12:02:18 +0000

Git for Beginners
Do you have want to know git commands, I got a rhetorical question what is git? Are you in a position to answer that.
Imagine writing a massive research paper. In the process making some edits, saving the file as paper.docx, and going to sleep. The next day, you want to try a new angle but don't want to lose your original work, so you save a new copy as paper_v2.docx. A few days later, your desktop is cluttered with files like paper_final.docx, paper_final_v3_actual_final.docx, and paper_shred_this_if_it_fails.docx.
Now, imagine doing this with thousands of lines of code, spread across hundreds of files, while working with five other developers. It would be an absolute nightmare.
This is exactly the chaotic problem that Git and Version Control solve. Whether you are an aspiring software developer, a student, or just curious about coding, learning Git is the single most important practical skill you can acquire today. Let’s dive in.
What is Version Control and Why Does It Matter?
At its core, a Version Control System (VCS) is a tool that tracks changes to a set of files over time. It acts like a time machine for your project, allowing you to view, modify, or revert back to previous states of your work without losing any data.
Without version control, software development faces severe bottlenecks:

Overwritten Code: If two people edit the same file simultaneously, whoever clicks "Save" last wins, destroying the other person's work.
No Safety Net: If you introduce a bug that breaks the entire app, finding exactly what broke and when becomes a needle-in-a-haystack problem.
Fear of Experimentation: Developers become afraid to try new features because they might permanently break the existing, working code.

A VCS solves all of this by keeping a flawless, chronological history of every single change made to a project, who made it, and why.

What is Git?
Git is a free, open-source Distributed Version Control System created in 2005 by Linus Torvalds (the same genius who created Linux).
"Distributed" means that every developer working on a project doesn't just check out the latest version of the files; they download a complete copy of the entire project history onto their local hard drive. If a central server goes offline, any developer's local repository can be used to restore the project completely.
In modern software development, Git is the industry standard. Virtually every tech company, from tiny startups to tech giants like Google and Microsoft, relies on Git to manage their codebases.
Git vs. GitHub: What's the Difference?
One of the most common points of confusion for beginners is mixing up Git and GitHub. They are closely related, but they are not the same thing.
Git is the tool. It is a command-line software application that runs locally on your computer to track your files and manage your project's history. You don't even need an internet connection to use Git.
GitHub is the home for your Git projects. It is a cloud-based hosting platform (a website) that stores your Git repositories online. It makes it easy to share your code with others, collaborate on projects, and back up your work.

Analogy: Think of Git like the camera on your smartphone (the tool that captures the photo), and GitHub like Instagram (the online platform where you upload and share those photos with the world).
Other alternatives to GitHub include GitLab and Bitbucket, but they all use Git under the hood.

Core Git Concepts Explained
Before we type any commands, let’s understand the basic vocabulary of Git:
Repository (or "Repo"): The container or folder where Git tracks your project files and their entire history.

Commit: A snapshot of your files at a specific point in time. Think of it like saving a game. If you make a mistake later, you can always load up an old commit.
Branch: A parallel version of your repository. By default, every repo has a main branch (usually called main or master). You can create a new branch to work on a feature safely without affecting the main production code.
Merge: The process of combining the histories and changes from one branch back into another (e.g., merging your completed feature branch back into the main branch).

-Remote Repository: A copy of your repository hosted on the internet or a network (like on GitHub), which allows multiple people to collaborate.