Chemaclass - cryptography

How Bitcoin Works

2025-12-22T00:00:00+00:00

This post explains how Bitcoin works under the hood. If you’re looking for why Bitcoin matters, start with Bitcoin Fundamentals.

For the technically curious.

The Blockchain #

The Double-Spend Problem #

Digital money has a fundamental problem: how do you prevent someone from copying their coins and spending them twice? Traditional systems solve this with a central authority (banks, PayPal) that tracks who owns what. Bitcoin’s breakthrough was solving this without any central party.

The solution: a shared ledger that everyone can verify but no one controls.

How It Works #

Bitcoin uses a blockchain: a chain of blocks where each block contains transactions and links to the previous block through cryptographic hashes.

A hash function takes any input and produces a fixed-size fingerprint. Change one bit of input, and the output changes completely. This makes tampering obvious. Bitcoin uses SHA-256, which produces a 256-bit output.

Each block contains:

A list of transactions
A hash of the previous block header
A proof-of-work solution (more below)

Before transactions get into a block, they wait in the mempool. Miners pick transactions from this pool, prioritizing those with higher fees. Watch this in real-time at mempool.space.

Every node keeps a complete copy of the blockchain. No single server to hack, no central database to corrupt. To change history, you’d need to rewrite blocks on the majority of nodes worldwide.

A block has two parts: the header (80 bytes) and the body (transactions).

The header contains:

Version: Protocol version
Previous block hash: Links to the chain
Merkle root: Hash of all transactions in the block
Timestamp: When the block was created
Difficulty target: How hard the puzzle was
Nonce: The solution miners found

Merkle trees organize transactions efficiently. Each transaction is hashed, then pairs of hashes are combined and hashed again, building up to a single root hash. This allows proving a transaction exists in a block without downloading all transactions. Useful for lightweight wallets.

Block weight is measured in virtual bytes (vB). The limit is 4 million weight units, roughly 1-1.5 MB of data per block.

Transactions & Cryptography #

The UTXO Model #

Bitcoin doesn’t use accounts with balances. Instead, it tracks Unspent Transaction Outputs (UTXOs). Think of them as digital coins of varying sizes.

When you receive bitcoin, you get a UTXO. When you spend, you consume entire UTXOs as inputs and create new ones as outputs. If you have a 1 BTC UTXO and want to send 0.3 BTC, you spend the whole UTXO and create two outputs: 0.3 BTC to the recipient and ~0.7 BTC back to yourself (minus fees).

Your “balance” is the sum of all UTXOs you can spend.

Public-Key Cryptography #

Bitcoin transactions use public-key cryptography:

Private key: A secret 256-bit number. This proves ownership.
Public key: Derived mathematically from the private key. Shared publicly.

When you send bitcoin, you sign the transaction with your private key. This signature proves you own the UTXOs being spent without revealing the private key. Anyone can verify the signature using your public key.

Programmable Money #

Bitcoin isn’t just digital cash. It has its own programming language called Script. Every transaction includes a small program that defines the conditions for spending.

Most transactions use simple scripts: “whoever can prove they own this public key can spend these coins.” But Script enables much more: multi-signature wallets requiring multiple keys, time-locked transactions that can’t be spent until a certain date, and complex conditions combining multiple requirements.

This makes Bitcoin programmable money. For a deeper dive into Script and address types, see Programmable Money.

Bitcoin uses ECDSA (Elliptic Curve Digital Signature Algorithm) with the secp256k1 curve. This curve was chosen for efficiency and because it wasn’t designed by any government agency (unlike NIST curves), reducing backdoor concerns.

A private key is a random 256-bit integer. The public key is derived by multiplying this number by a generator point on the curve. Easy to compute forward, practically impossible to reverse.

Transaction signing involves:

Hashing the transaction data
Creating a signature using the private key
Including the signature and public key in the transaction

SIGHASH flags control what parts of a transaction the signature covers:

SIGHASH_ALL: Signs all inputs and outputs (most common)
SIGHASH_NONE: Signs inputs only
SIGHASH_SINGLE: Signs one specific output
These can be combined with ANYONECANPAY for advanced use cases

Mining & Consensus #

How does a decentralized network agree on which transactions are valid? Through proof-of-work mining.

The Puzzle #

Miners race to find a number (the nonce) that, when combined with the block header and hashed, produces a result below a target value. It’s like rolling dice until you get a number under 100, except with 2^256 possible outcomes.

The work is:

Hard to find: Requires trillions of guesses
Easy to verify: One hash check proves the solution

This asymmetry is key. Anyone can verify a block instantly, but creating one requires real computational work.

Why It Matters #

Mining serves three purposes:

Secures the network: Rewriting history means redoing all hash work
Issues new coins: Following a predictable schedule (halving every 210,000 blocks)
Processes transactions: Including them in the permanent record

Every 2016 blocks (~2 weeks), the network adjusts difficulty to maintain ~10 minute block times. More hashpower joins? Puzzles get harder. Hashpower leaves? Puzzles get easier.

Explore mining pools and hashrate at mempool.space/mining.

Difficulty calculation: The target is a 256-bit number. A valid block hash must be below this target. Lower target = harder puzzle. The network adjusts every 2016 blocks based on how long those blocks actually took vs. the expected 20,160 minutes.

Hashrate and security: Bitcoin’s security comes from the cost to rewrite history. With ~500 EH/s (exahashes per second) of hashrate, attacking the network would require controlling majority hashpower. That means billions in hardware and electricity, plus the attack would crash the asset’s value.

Economic incentives: Miners spend real resources (electricity, hardware). They only profit if they play by the rules. A miner who creates invalid blocks wastes their work because nodes reject invalid blocks. This aligns individual profit motive with network security.

51% attacks: If an attacker controlled majority hashrate, they could theoretically double-spend by mining an alternative chain. But the economics make this irrational for large values: the attack destroys the value of what you’re stealing.

Addresses & Wallets #

Bitcoin addresses are derived from public keys. Different formats have evolved:

P2PKH: Legacy addresses starting with “1”
P2SH: Script addresses starting with “3”
P2WPKH: Native SegWit addresses starting with “bc1q”
P2TR: Taproot addresses starting with “bc1p”

For technical details on each type, see Programmable Money.

Wallets #

A wallet manages your keys and constructs transactions. It doesn’t hold your coins. Coins exist on the blockchain. The wallet holds keys that prove you can spend them.

Hot wallets connect to the internet. Convenient for daily use, more vulnerable. Examples: phone apps, browser extensions.

Cold wallets stay offline. More secure for savings. Examples: hardware wallets (Ledger, Trezor), paper wallets.

HD Wallets and Seed Phrases #

Modern wallets are Hierarchical Deterministic (HD). One master seed generates unlimited keys in a tree structure. Back up the seed once, recover everything.

BIP-39 defines the 12 or 24-word seed phrase most wallets use. These words encode entropy that derives all your keys. Lose the phrase, lose access. Anyone with the phrase controls the funds.

Never store seed phrases digitally. Write them down. Store securely offline.

How big is the BIP-39 keyspace, really? I built seed-hunter, an open-source educational Go CLI that tries to brute-force a 12-word seed against the real Bitcoin network. It logs every attempt and shows live progress with ETAs spanning 10²⁹ to 10³⁹ years. A burglar checking one trillion seed phrases per second since the Big Bang would have completed 0.000_000_008% of the search by now. The point isn’t to break Bitcoin, it’s to make the math viscerally obvious: thermodynamics, not just computation, forbids the attack.

The Network #

Bitcoin is a peer-to-peer network. No central servers. Nodes connect to each other, share transactions and blocks, and enforce rules independently.

Node Types #

Full nodes download and validate every block and transaction. They enforce all consensus rules and don’t trust anyone. Running a full node means you verify everything yourself.

SPV (light) clients only download block headers. They trust that miners validated the transactions. Less security, but works on phones and low-power devices.

Mining nodes are full nodes that also compete to create new blocks.

How Transactions Propagate #

When you broadcast a transaction:

Your wallet sends it to connected nodes
Each node validates and forwards to its peers
Within seconds, the transaction reaches most of the network
Miners include it in their candidate blocks

Blocks propagate similarly. When a miner finds a valid block, it spreads across the network in seconds.

Peer discovery: Nodes find each other through DNS seeds (hardcoded addresses that return active node IPs) and by sharing peer addresses with connected nodes.

Gossip protocol: Information spreads through “inv” (inventory) messages. A node announces it has something new, peers request it if interested. This prevents bandwidth waste from duplicate data.

Compact blocks (BIP-152) speed up block propagation. Since nodes already have most transactions in their mempool, blocks can be transmitted as just the header plus short transaction IDs.

Security & Confirmations #

Why Confirmations Matter #

When a transaction is included in a block, it has 1 confirmation. Each subsequent block adds another confirmation.

More confirmations = harder to reverse. To undo a confirmed transaction, an attacker would need to mine an alternative chain faster than the honest network. Each block makes this exponentially harder.

General guidelines:

0 confirmations: Transaction broadcast but not yet in a block. Can be double-spent.
1 confirmation: In a block. Reversal requires significant hashpower.
6 confirmations: Standard for large amounts. Reversal practically impossible.

Satoshi’s whitepaper includes the probability calculation. With an attacker controlling fraction q of hashpower:

If q < 0.5: Probability of catching up decreases exponentially with each confirmation
At 6 confirmations with q = 0.1 (10% hashpower): Success probability < 0.1%

The “6 confirmations” rule assumes a well-funded attacker with substantial but minority hashpower. For smaller transactions, fewer confirmations are often acceptable.

Finality in Bitcoin is probabilistic, not absolute. But after enough confirmations, the probability of reversal approaches zero for any realistic attacker.

Incentive Alignment #

Bitcoin isn’t just a clever technology. It’s a system where every participant’s self-interest reinforces the network.

Miners invest in hardware and electricity. They only profit by producing valid blocks. Cheating wastes their investment because nodes reject invalid blocks instantly.
Nodes enforce the rules to protect their own holdings. A node operator who accepts invalid transactions devalues their own bitcoin. Self-interest makes them honest validators.
Users pay fees to get transactions processed. Higher fees mean faster confirmation. This creates demand for block space and funds network security.
Developers contribute to software they themselves use. Bugs hurt their own holdings. Improvements benefit everyone, including them.
Holders benefit from network security and adoption. The more secure and useful Bitcoin becomes, the more valuable their holdings. They’re incentivized to support the ecosystem.

No central coordinator. No trust required. Everyone acts in their own interest, and the system benefits everyone.

“Don’t trust, verify.” Anyone can run a node and verify every transaction, every block, every rule. You don’t need to trust banks, governments, or even other Bitcoin users. The math proves itself.

Scaling: The Lightning Network #

Bitcoin’s base layer processes about 7 transactions per second. That’s by design: keeping things decentralized requires blocks small enough for anyone to verify. But this limits how many transactions it can handle.

The Lightning Network solves this with a second layer built on top of Bitcoin. It enables:

Instant payments: No waiting for block confirmations
Near-zero fees: Fractions of a cent
High capacity: Millions of transactions per second

Lightning works by opening “payment channels” between parties. Transactions within a channel happen off-chain, instantly. Only the opening and closing of channels require on-chain transactions. You can visualize the network topology and statistics at mempool.space/lightning.

Bitcoin’s base layer provides security and final settlement. Lightning provides speed and scale. Different tools for different jobs.

If you want to run your own Lightning node and take full control of your payments, I wrote a guide on how to Run your LN node on a Raspberry Pi.

Payment channels use 2-of-2 multisig addresses. Both parties must sign to move funds. This creates a shared account that neither can steal from.

HTLCs (Hash Time-Locked Contracts) enable multi-hop payments. The mechanism:

Alice wants to pay Carol through Bob
Carol generates a secret and gives Alice the hash
Alice creates an HTLC: “Bob gets paid if he reveals the secret within 24 hours”
Bob creates a similar HTLC with Carol
Carol reveals the secret to Bob, claiming payment
Bob uses the same secret to claim from Alice

If anyone fails to cooperate, the timelock expires and funds return. The secret travels backward, payments travel forward.

Watchtowers monitor the blockchain for cheating attempts. If your counterparty tries to broadcast an old channel state, the watchtower can penalize them, even while you’re offline.

The Bigger Picture #

What makes Bitcoin remarkable isn’t any single component. It’s how they fit together into a self-reinforcing system.

Cryptography proves ownership without trusted authorities. Proof-of-work makes history expensive to rewrite. Economic incentives turn individual greed into collective security. Decentralization removes single points of failure. And the fixed supply creates digital scarcity for the first time in history.

Every piece supports every other piece. Remove one, and the system weakens. Together, they create something that has never existed before: money that can’t be inflated, transactions that can’t be censored, and property that can’t be confiscated.

No banks. No governments. No trusted third parties. Just math, code, and a global network of nodes all enforcing the same rules.

Whether that matters to you depends on where you live and how much you trust your institutions. But the option exists now. And no one can take it away.

Bitcoin’s technical depth goes far beyond what fits in one post. Here are topics worth exploring if you want to go deeper:

SegWit (Segregated Witness) was Bitcoin’s 2017 upgrade that moved signature data outside the main transaction structure. This fixed transaction malleability (a bug that prevented Lightning), introduced block weight for more efficient space usage, and did it all while staying backwards-compatible with old nodes.

Taproot & Schnorr landed in 2021, upgrading Bitcoin’s cryptography. Schnorr signatures are smaller and enable aggregation (multiple signatures become one). Taproot makes complex spending conditions look identical to simple payments on-chain, improving both privacy and efficiency.

Soft forks vs hard forks: How does Bitcoin upgrade without a central authority? Soft forks add new rules that old nodes still accept. Hard forks change rules in ways old nodes reject. Understanding this distinction explains why Bitcoin evolves slowly and why contentious changes are rare.

Fee mechanics: The fee market is more nuanced than “pay more, confirm faster.” Replace-By-Fee (RBF) lets you bump a stuck transaction’s fee. Child-Pays-For-Parent (CPFP) lets recipients accelerate incoming payments by spending them with high fees.

Timelocks: Bitcoin can lock funds until conditions are met. CLTV (CheckLockTimeVerify) locks until a specific block height or timestamp. CSV (CheckSequenceVerify) locks for a relative time after confirmation. These primitives enable Lightning channels, inheritance schemes, and atomic swaps.

Coinbase transactions: The only way new bitcoin enters circulation. Every block begins with a special transaction that pays the miner the block reward plus all fees. These newly minted coins can’t be spent for 100 blocks, a rule that protects against chain reorganizations.

The deeper you go, the more you find.

The Cypherpunks

2024-12-11T00:00:00+00:00

In the early ’90s, with the internet on the rise, a group called the Cypherpunks emerged to defend digital privacy. They pushed for encryption and privacy, shaping our digital world with their vision.

Who were the Cypherpunks? #

The term “Cypherpunk” combines “cipher” (a reference to encryption) with “punk”, reflecting the group’s rebellious and anti-establishment spirit.

Far from being a formal organization, the Cypherpunks were a diverse assembly of visionaries, technologists, and activists bonded by shared principles. The movement started in 1992 when Eric Hughes, Timothy May, and John Gilmore founded the cypherpunks mailing list. Some key figures:

Eric Hughes who wrote “A Cypherpunk’s Manifesto,” laying out the philosophical foundation for the movement.
Timothy C. May authored “The Crypto Anarchist Manifesto,” which imagined a society where cryptography could foster a new anarchistic order.
John Gilmore, a co-founder of the Electronic Frontier Foundation (EFF), was pivotal in early internet privacy advocacy.
Julian Assange, later known for WikiLeaks, participated in these discussions.
Phil Zimmermann revolutionized email privacy with his creation of PGP.
Jude Milhon (St. Jude), a hacker and writer, coined the term “cypherpunk” together with Eric Hughes.
Nick Szabo contributed significantly to digital contracts and currencies, conceptualizing “bit gold” before Bitcoin.
Hal Finney, an early Bitcoin developer, worked on cryptographic software including PGP, influencing the privacy tech landscape.
Adam Back introduced Hashcash, which later inspired Bitcoin’s proof-of-work, while actively engaging in cypherpunk dialogues on privacy.
Wei Dai proposed “b-money,” an early idea for anonymous digital cash systems, which influenced Bitcoin’s development.
Zooko Wilcox-O’Hearn, with his work on Zcash, brought advanced privacy to cryptocurrencies, having roots in cypherpunk discussions.
David Chaum, often called the “godfather of cypherpunks”, pioneered digital cash with DigiCash (1989). His work on electronic privacy predates and inspired the movement.
Bram Cohen developed BitTorrent, showcasing the cypherpunk ethos of decentralization in file sharing.

Their work built on foundational cryptographic research by Whitfield Diffie and Martin Hellman, who invented public-key cryptography in 1976, making secure communication between strangers possible.

They gathered online on the cypherpunks mailing list, which at its peak had around 2000 subscribers exchanging 30+ messages per day. Their motto: “Cypherpunks write code.” They didn’t just talk about privacy. They built it.

Philosophy and goals #

The core philosophy of the Cypherpunks was centered around privacy, freedom of speech, and the potential of cryptography to protect these rights. Their main tenets included:

Privacy as a fundamental right: They believed that privacy was essential for personal freedom and that digital communication should be private.
Decentralization: Suspicious of centralized control over information, they pushed for decentralized systems where individuals could control their own data.
Cryptography as a tool: They saw encryption not just as a means of securing data but as a political tool against surveillance and oppressive regimes.

Their goals were #

To create and promote tools for encryption, anonymity, and digital cash.
To educate the public on the importance of cryptography.
To resist governmental and corporate efforts to control or monitor digital communications.

Impact nowadays #

Development of key technologies #

Cypherpunks built tools, not just theories:

PGP (1991): Email encryption for everyone
Tor (2002): Anonymous browsing through onion routing
BitTorrent (2001): Decentralized file sharing
Bitcoin (2009): Digital money without banks
Signal Protocol: The encryption behind Signal, WhatsApp, and other messengers

When you send an encrypted message today, you’re using cypherpunk technology.

Cultural shift #

They changed how society views privacy. Before them, encryption was mostly for governments or experts. Today, it’s a standard part of tools like messaging apps and web browsers. By promoting encryption and anonymity, they made privacy a priority and encouraged people to take control of their data.

Legal and policy influence: The Crypto Wars #

The 1990s saw a real battle between cypherpunks and governments, known as the “Crypto Wars.” The US classified strong encryption as a weapon and banned its export. When Phil Zimmermann released PGP, he was investigated for “exporting munitions” because the software spread globally via the internet.

The cypherpunks fought back creatively. They printed PGP source code in books, since books were protected speech. They wore t-shirts with encryption code. Eventually, they won. Export restrictions were relaxed in 2000. Today’s encrypted messaging exists because of that fight.

Challenges and Criticisms #

The Cypherpunks face these main criticisms:

Accessibility: Their tools are too complex for many people, so only tech-savvy individuals can use them, leaving others behind.
Misuse Risk: There’s concern that their encryption tech could be used by bad actors. While Cypherpunks believe privacy is a right for all, this view conflicts with security concerns from authorities who fear these tools could hide illegal acts.

This shows the ongoing struggle between promoting privacy and maintaining safety in the digital world.

Precursors to Bitcoin #

Bitcoin is the most well-known outcome of the cypherpunk philosophy, embodying their values of decentralization, privacy, and independence from government control over money. Created by the mysterious Satoshi Nakamoto, Bitcoin was first shared with the world through the cypherpunks’ mailing list in 2008.

However, it is the result of many trials of other technologies also created within this group of people. It uses ideas like proof-of-work from Hashcash, and concepts from b-money and bit gold, all reflecting the cypherpunks’ dream of a currency not controlled by any single entity.

DigiCash (eCash) #

Developed by David Chaum in the late 1980s and implemented in 1990, DigiCash was one of the earliest attempts at an electronic payment system. It used cryptography to ensure privacy in transactions but struggled with adoption and eventually failed due to issues like centralization and the double-spending problem.

B-Money #

Proposed by Wei Dai in 1998, B-Money was a conceptual framework for anonymous, distributed electronic cash. It aimed to solve issues like double-spending without a central authority but was never implemented. Its ideas influenced Bitcoin’s design.

Bit Gold #

Also conceptualized in 1998 by Nick Szabo, Bit Gold proposed a currency with properties similar to gold, using cryptographic proof-of-work. Like B-Money, it was never fully realized but contributed to Bitcoin’s development, particularly its proof-of-work system.

Hashcash #

Introduced by Adam Back in 1997, Hashcash was not a currency but a system to counter email spam using proof-of-work. This concept was later adopted by Bitcoin for mining.

These earlier projects and ideas, while not successful in creating a functional digital currency, were critical in laying the theoretical groundwork for Bitcoin. They tackled issues like double-spending, privacy, and decentralization, which were key problems Bitcoin aimed to solve.

Cypherpunk legacy #

Bitcoin has revolutionized our understanding of money, privacy, and security:

Decentralized Control: Bitcoin isn’t run by any bank or government, which fits perfectly with the cypherpunk’s skepticism of centralized power.
Privacy: While not completely anonymous, Bitcoin transactions use pseudonyms, offering some protection from financial oversight.
Immutable Transactions: Once a transaction is on the blockchain, it’s nearly unchangeable, fostering trust in digital dealings.

Bitcoin has brought cypherpunk ideals to life, sparking global discussions on financial privacy, money’s nature, and cryptography’s transformative power. With developments like the Lightning Network for faster, private transactions and Taproot for enhanced transaction privacy, Bitcoin continues to evolve.

What the cypherpunks left behind #

The cypherpunks proved that a small group of people who write code can change the world. Every encrypted message you send, every Bitcoin transaction, every anonymous browse: their legacy.

Privacy isn’t dead. They made sure of that.

Related links

Learn more: What is PGP encryption? A 3-minute tutorial for beginners
Wikipedia Article: wikipedia.org/Cypherpunk

Verified Git Commits

2024-11-17T00:00:00+00:00

When it comes to software development, trust and security are very important. One easy way to level up both is by using verified commits.

Whether you’re working on an open-source project or in a private company, verified commits can make sure your contributions are legit. Let’s break down what they are, why they’re important, and how to start using them.

What are verified commits? #

A verified commit is basically a Git commit that is signed by the author using a digital signature. This signature proves that the commit actually came from the person who says they made it. Tools like GPG (GNU Privacy Guard) let you attach this signature to your commits.

If you’re using platforms like GitHub, you’ll notice a little “Verified” badge next to commits that are signed properly. It’s a quick way to show that the commit is authentic.

Why Are They Important? #

Signed commits help keep your contributions authentic and trustworthy. By adding a cryptographic signature to your commits, you prove that the changes came from you. This is especially important in collaborative environments, where maintaining trust and accountability is key.

Without signed commits, anyone could fake a commit using someone else’s email. For example, they could use your email, and platforms like GitHub would link it to your profile, making it look like you made the changes, even if you didn’t… not good!

By signing your commits, you show that the work is genuinely yours. It stops impersonation, builds trust in what you’ve done, and keeps everything transparent and accountable.

Note: For this demo, I used a public email address belonging to Linus Torvalds. After pushing the commit to this repository, GitHub recognized the email and linked it to his profile. This impersonation is purely for demo purposes to highlight potential risks. Always use your own email for commits.

How to get started with verified commits #

Set up a GPG key #

First, you’ll need a GPG key to start signing commits. Here’s how:

Generate a GPG key:

gpg --full-generate-key

Find your key ID:

gpg --list-secret-keys --keyid-format=long

Tell Git to use your key:

git config --global user.signingkey <your-key-id>

Make signing commits the default:

git config --global commit.gpgsign true

Add your key to GitHub/GitLab #

Export your public key:

gpg --armor --export <your-key-id>

Navigate to “Settings > SSH and GPG keys,” and paste your key.

Start signing commits #

From now on, Git will automatically sign your commits.

If you want to sign a commit manually, just use the -S flag:

git commit -S -m "Your commit message"

You can verify the commit signature with:

git log --show-signature

And also when clicking on the “Verified” badge on GitHub directly.

Verified commits might seem like a small step, but they make your code more trustworthy. It’s an easy way to add an extra layer of protection to your work, and it’s worth it. Give it a try!

Extra: Full setup in Spanish 🇪🇸 #

Related links

Learn more: What is PGP encryption? A 3-minute tutorial for beginners

Pretty Good Privacy

2024-07-13T00:00:00+00:00

PGP (Pretty Good Privacy) is an encryption program that ensures privacy and authentication for data communication. It is used for signing, encrypting, and decrypting texts, emails, files, directories, and whole disk partitions.

History #

PGP was developed by Phil Zimmermann out of concern for the lack of privacy in digital communications. He aimed to provide individuals with strong encryption tools. In 1991, PGP was released to the public for free, marking the beginning of a new era in digital security.

Legal Challenges #

In the early 1990s, strong encryption was classified as a weapon under U.S. export law. When PGP spread globally via the internet, Zimmermann faced a criminal investigation for “exporting munitions.”

His defense was clever: he published the PGP source code in a book. Books are protected speech. The case was dropped in 1996, and encryption export restrictions were eventually relaxed in 2000.

Key Features #

Encrypts and decrypts data to ensure secure communication
Provides authentication to verify the identity of senders and receivers
Generates public and private keys for secure key exchange
Supports various encryption algorithms and hash functions

Today, PGP lives on as OpenPGP (the standard) and GPG (GNU Privacy Guard, the free implementation). When you verify a software download or sign a git commit, you’re often using GPG.

How it works #

PGP uses a combination of public-key and symmetric-key to ensure secure data transmission. It generates a keypair consisting of a public key and a private key. The public key is shared with others, while the private key is kept secret. When data is encrypted, it is encrypted with the public key, and only the corresponding private key can decrypt it.

Symmetric Key Encryption: PGP generates a unique, one-time-use session key to encrypt the message. This method is fast and efficient but requires the sender and recipient to share the same key securely.
Asymmetric Key Encryption: PGP solves the key exchange problem with asymmetric encryption. Each user has a public key and a private key. The session key is encrypted with the recipient’s public key and can only be decrypted by the recipient’s private key.
Digital Signatures: PGP provides authentication through digital signatures. The sender signs the message with their private key, allowing the recipient to verify the sender’s identity using the sender’s public key, ensuring the message has not been tampered with.

My public key #

Fingerprint #

56D5 D60B 0934 0999 199C 3750 E51B 5BF4 5F85 D160

Import directly #

curl https://chemaclass.com/pgp.asc | gpg --import

Download the .asc file #

Download public PGP key

Programmable Money

2024-07-06T00:00:00+00:00

Bitcoin is often referred to as “programmable money” because it allows for the execution of programmable transactions through its scripting language.

Understanding Programmable Money #

Programmable money is the ability to embed logic and conditions into financial transactions. This programmability allows transactions to be executed automatically based on predefined rules without intermediaries or manual intervention. It transforms money from a static medium of exchange into a dynamic tool capable of executing complex agreements and automating financial operations.

The Script Language #

Bitcoin’s programmability is powered by its built-in scripting language, Script. Unlike traditional programming languages, Script is a stack-based, Forth-like language explicitly designed for Bitcoin transactions.

It supports multi-signature, time-locked, and other conditional transfers that can be programmed into Bitcoin transactions. It is intentionally not Turing-complete, without loops.

This video includes examples of the most commonly used locking/unlocking scripts.

Key Features of Bitcoin’s Script #

Stack-Based Execution #

Script operates on a stack-based execution model where commands and data are pushed onto a stack and processed in a Last-In-First-Out (LIFO) manner.

Conditional Spending #

A transaction that can only be spent if certain data is provided or specific criteria are met. This can be used for:

escrow services
atomic swaps
and other complex financial arrangements

Multisignature #

Transactions can be set up to require multiple signatures from different private keys before they can be spent. Useful for:

joint accounts
corporate funds
and enhancing security, as no single party can unilaterally spend the funds

Timelocking #

Transactions can include time-based conditions that prevent them from being spent until a certain time or block height is reached. This feature is useful for various purposes:

delayed payments
smart contracts
and ensuring that funds are not spent prematurely (eg: with Lightning Network)

Operation Codes #

Bitcoin’s Script performs specific operations within transactions with its OP_Codes. Here are some of them:

OP_DUP: Duplicates the top stack item.
OP_HASH160: Hashes the top stack item twice (SHA-256 followed by RIPEMD-160).
OP_EQUALVERIFY: Verifies that the top two items are equal and removes them.
OP_CHECKSIG: Verifies a signature against a public key.
OP_RETURN: Marks the transaction output as invalid, often used to store data.

Common Bitcoin address types #

In Bitcoin, different address types correspond to various ways to script transactions. Here, we’ll explore examples of Bitcoin Script for each major address type. Each address type has its own specific script format.

P2PK: Earliest legacy transactions using full public keys directly.
P2PKH: Begins with 1. Legacy transactions using public key hashes.
P2SH: Begins with 3. Legacy, encapsulates complex scripts like multisig.
P2MS: It is typically a type of P2SH or P2WSH address.
P2WPKH: Begins with bc1. Native SegWit, more efficient transactions.
P2WSH: Begins with bc1. SegWit for complex scripts.
P2TR: Begins with bc1p. SegWit Taproot addresses, improving privacy and efficiency for complex transactions.

Using native SegWit (P2WPKH and P2WSH) is preferable when possible, as it maximizes the benefits of the SegWit upgrade, but P2SH-SegWit can be useful for compatibility with older systems.

P2PK (Pay-to-PubKey) - Earliest Legacy Address up #

Begins with "1" (e.g., 1A1zP1eP5QGefi2DMPTf...v7DivfNa)

Before P2PKH and P2SH became standard, Bitcoin addresses were not as flexible or feature-rich. Here are some considerations:

Addresses starting with 1 but without hashing the public key.
Not common in modern practice due to lack of privacy and efficiency.
The P2PK format is largely obsolete in favor of (at very least) P2PKH.

P2PKH (Pay-to-PubKey-Hash) - Legacy Address up #

Begins with "1" (e.g., 1A1zP1eP5QGefi2DMPTf...v7DivfNa)

A typical P2PKH script consists of two main parts:

ScriptPubKey: The locking script (also known as the output script) that specifies how funds can be spent.
ScriptSig: The unlocking script (also known as the input script) that provides the necessary data to unlock the funds.

ScriptPubKey (Locking Script) #

OP_DUP OP_HASH160 <PubKHash> OP_EQUALVERIFY OP_CHECKSIG

OP_DUP: Duplicates the top stack item (the public key).
OP_HASH160: Hashes the public key with SHA-256 followed by RIPEMD-160.
<PubKHash>: The hashed public key (a 20-byte value).
OP_EQUALVERIFY: Checks if the hashed public key matches the hash in the script.
OP_CHECKSIG: Verifies the provided signature against the public key.

ScriptSig (Unlocking Script) #

<sig> <PubK>

<sig>: The digital signature generated by the private key.
<PubK>: The public key corresponding to the address.

Execution Flow #

The ScriptSig (unlocking script) is pushed onto the stack.
The ScriptPubKey (locking script) is executed.

P2SH (Pay-to-Script-Hash) up #

Begins with "3" (e.g., 3J2BtwzN2GEr6FCP.....81T2eiX8PVHh)

P2SH scripts are used for more complex scripts. The primary feature is that the address itself encodes a hash of a script, which will be used in the transaction.

ScriptPubKey (Locking Script) #

OP_HASH160 <ScriptHash> OP_EQUAL

OP_HASH160: Hashes the script with SHA-256 followed by RIPEMD-160.
<ScriptHash>: The hashed script (a 20-byte value).
OP_EQUAL: Checks if the hash matches the provided script hash.

ScriptSig (Unlocking Script) #

<sig> <PubK> ... <ScriptSig>

<sig>: The digital signature.
<PubK>: The public key.
<ScriptSig>: The actual script that matches the script hash, which itself will be executed by the Bitcoin network.

P2MS (Pay-to-Multisig) up #

Script Format #

OP_M <M> <PubK1> <PubK2> ... <PubKN> OP_N OP_CHECKMULTISIG

OP_M: The minimum number of signatures required.
<PubK1>, <PubK2>, ..., <PubKN>: The public keys involved in the multisignature scheme.
OP_N: The total number of public keys provided.
OP_CHECKMULTISIG: The opcode that verifies the signatures against the provided public keys.

ScriptPubKey (Locking Script) #

OP_2 <PubK1> <PubK2> <PubK3> OP_3 OP_CHECKMULTISIG

This script means that any 2 out of 3 provided public keys are required to sign the transaction for it to be valid.

ScriptSig (Unlocking Script) #

<sig1> <sig2> ... <sigN> <SerializedScript>

<sig1>, <sig2>, ..., <sigN>: The public keys.
<SerializedScript>: The serialized script (the same as the locking script but without the OP_M and OP_N).

NOTE: There is an oddity in CHECKMULTISIG execution. See note at the bottom.

P2WPKH (Pay-to-Witness-Public-Key-Hash) - Segwit up #

Begins with "bc1q" (e.g., bc1qf0r2m0ck4psv6yrk9w.....kw8v5rj7ph3)

P2WPKH is a Segregated Witness (SegWit) address type that uses a different scripting format compared to legacy and P2SH addresses. Simplifies transactions by reducing data size and fees compared to legacy formats.

ScriptPubKey (Locking Script) #

OP_0 OP_PUSHBYTES_20 <PubKHash>

OP_0: A single byte (0x00) indicating the version of the script.
OP_PUSHBYTES_20: Pushes 20 bytes (the public key hash) onto the stack.
<PubKHash>: The 20-byte hash of the public key.

Witness Data #

For P2WPKH, the unlocking script is not required in the traditional sense (i.e., inside the unlocking script explicitly included in the transaction input). Instead, the unlocking information is provided as part of the witness data in the SegWit transaction format.

<sig> <PubK>

<sig>: Digital signature for the transaction.
<PubK>: Public key used to generate the public key hash.

P2WSH (Pay-to-Witness-Script-Hash) - Segwit up #

Begins with bc1q (e.g.: bc1q4a3h5sdg4cfkhftgd24tj9g2sg...yj57jmfckhkrw5gslr9g59)

ScriptPubKey (Locking Script) #

OP_0 OP_PUSHBYTES_32 <ScriptHash>

OP_0: Indicates a witness version 0 (SegWit).
OP_PUSHBYTES_32: Pushes the next 32 bytes (the script hash) onto the stack.
<ScriptHash>: 32-byte hash of the redeem script.

Witness Data #

<sig1> <sig2> ... <RedeemScript>

<sig1>, <sig2>: Signatures required to unlock the transaction.
<RedeemScript>: The actual script that matches the script hash. This script will be executed as part of the witness data.

P2TR (Pay-to-Taproot) - Taproot up #

Begins with bc1p (e.g.: bc1pl9dfv7kvj4hj9s3a8l.....gjstmrpjl09g8ks3ukds70q4r2j5h)

Taproot combines Schnorr signatures with MAST, enabling private, efficient spending conditions and making complex transactions appear standard unless conditions are revealed. It allows the efficient execution of complex transactions while hiding their details.

ScriptPubKey (Locking Script) #

OP_1 <x-only PubK>

OP_1: Indicates a witness version 1 (Taproot).
<x-only PubK>: A 32-byte Schnorr public key (without the y-coordinate).

Witness Data #

<sig>

<sig>: A Schnorr signature proving possession of the private key corresponding to the x-only pubkey.

*There is an oddity in CHECKMULTISIG execution up #

The implementation of OP_CHECKMULTISIG pops one more item than it should. The extra item is disregarded when checking the signatures, so it has no direct effect on the OP itself. It must be present because if OP_CHECKMULTISIG attempts to pop on an empty stack, it will cause a stack error and script failure.

OP_0 <sig2> <sig3> 2 <PubK1> <PubK2> <PubK3> 3 OP_CHECKMULTISIG

The input script in this multisig is not <sig2> <sig3> but OP_0 <sig2> <sig3>.

It became the custom early on to use OP_0, which later became a relay policy rule and eventually a consensus rule (BIP147).

It is possible that the original developer added the extra element in the original version of Bitcoin, so they could add a feature for allowing a map to be passed in a later soft fork (for performance reasons). However, that feature was never implemented, and the BIP147 update to the consensus rules in 2017 makes it impossible to add that feature in the future.

Only Bitcoin’s original developer could tell whether the dummy stack element was the result of a bug or a plan for a future upgrade. From now on, if you see a multisig script, you should expect to see an extra OP_O in the beginning, whose only purpose is as a workaround to an oddity in the consensus rules.

Follow-ups #

Official docs of Script in the Bitcoin Wiki.
Bitcoin IDE is an online Bitcoin Script visual emulator. Great for learning purposes.
Script Editor is product-driven research on Bitcoin scalability and usability.
Miniscript is a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing, and more.