This post is part of my deep dive into Bitcoin’s core architecture — studying directly from the official Bitcoin Developer Guide.
It summarizes everything I’ve learned so far before moving on to advanced topics like wallet architecture, the P2P network, and Taproot.
🧩 1. Bitcoin Overview
Bitcoin is a decentralized ledger that records all transactions without a central authority.
It achieves trustless consensus through cryptography, distributed nodes, and the Proof-of-Work mechanism.
Each node maintains a full copy of the blockchain — a chain of blocks that reference one another using cryptographic hashes.
💸 2. Transactions: The Heart of Bitcoin
Every Bitcoin transaction consists of inputs and outputs:
Input: References a previous unspent transaction output (UTXO).
It includes the public key and signature to unlock those funds.Output: Defines the new recipient’s address (as a public key hash) and the amount being sent.
When Alice sends Bitcoin to Bob:
- Her wallet creates a transaction using her UTXOs as inputs.
- It generates an unlocking script (scriptSig) with her public key and signature.
- The output specifies Bob’s public key hash — the new UTXO that only Bob can spend later.
🧮 3. Validation and the Memory Pool
When Alice’s transaction is broadcast:
-
Each node verifies it by checking:
- The referenced UTXOs exist and are unspent.
- The signature is valid.
- Inputs are larger than outputs.
- The fee is above the minimum relay fee.
Once validated, it’s added to the mempool (memory pool), where it waits to be mined.
Miners then pick transactions from the mempool, prioritizing those with higher fees.
⛏️ 4. Mining and Block Creation
Miners collect valid transactions into a block, which contains:
- Version – protocol version number
- Previous Block Hash – reference to the last block
- Merkle Root – summary of all transaction hashes in the block
- Timestamp – time when block was created
- Difficulty Target – defines how hard the block is to mine
- Nonce – value miners adjust to find a valid hash
Proof-of-Work (PoW)
To add a new block, miners must find a nonce that makes the block’s hash lower than the target difficulty.
This ensures that creating blocks requires computational work and prevents tampering.
If anyone changes even one transaction, the Merkle root changes →
the block hash changes → all subsequent blocks become invalid.
💰 5. Coinbase Transaction and Rewards
Each block starts with a coinbase transaction, which:
- Rewards the miner with newly created bitcoins (block subsidy).
- Collects all transaction fees in that block.
This coinbase transaction is mandatory under the consensus rules.
As block subsidies halve every 210,000 blocks, miners will eventually rely solely on transaction fees.
🔒 6. SegWit: Making Transactions More Efficient
The Segregated Witness (SegWit) upgrade moved signatures and public keys
from the scriptSig to a separate witness field, reducing transaction size and cost.
Benefits:
- Lower fees (because signatures no longer count fully toward byte size).
- Fixed transaction malleability.
- Enabled second-layer solutions like the Lightning Network.
⚙️ 7. Fee Policies and Mempool Rules
Bitcoin nodes implement several fee and safety policies:
| Policy | Description |
|---|---|
| Minimum Relay Fee | Reject transactions with fees below a certain threshold. |
| Dust Limit | Prevents outputs too small to be spent later. |
| Ancestor/Descendant Limit | Limits chains of unconfirmed transactions to avoid mempool flooding. |
| Replace-By-Fee (RBF) | Allows resending the same transaction with a higher fee. |
| Child-Pays-for-Parent (CPFP) | A child transaction can pay a higher fee to help confirm its parent. |
These rules maintain efficiency and fairness within the network.
⚡ 8. Advanced Scripts: Multi-Signature and Timelocks
Bitcoin’s scripting system allows conditional spending — making Bitcoin programmable.
🧾 Multi-Signature
A multisig script requires multiple signatures to unlock funds, such as:
This means 2 of 3 participants must sign to spend the funds.
Used in Lightning Network channels and escrow systems.
⏳ Timelocks
Timelocks restrict when funds can be spent:
| Type | Opcode | Description |
|---|---|---|
| Absolute Timelock | CHECKLOCKTIMEVERIFY (CLTV) |
Funds are locked until a specific block height or timestamp. |
| Relative Timelock | CHECKSEQUENCEVERIFY (CSV) |
Funds are locked for a certain number of blocks after confirmation. |
These opcodes enable secure payment channels like Lightning Network.
⚡ Lightning Network Connection
In Lightning:
-
CLTVsets an absolute timeout for a channel. -
CSVenforces a relative delay when closing a channel. This delay gives the honest party time to react if someone tries to cheat by broadcasting an old channel state.
🔗 9. Consensus and Immutability
Consensus ensures all nodes agree on the same blockchain state.
- Each node selects the longest valid chain (most cumulative Proof-of-Work).
- Any modification to old blocks changes their hashes, breaking the chain.
- This immutability guarantees transparency and trust.
🧠 10. What I’ve Learned
- Bitcoin’s security comes from cryptography, distributed consensus, and Proof-of-Work.
- Every transaction is traceable through UTXOs, making the system auditable.
- Scripts like multisig and timelocks add flexibility to Bitcoin’s functionality.
- Understanding the mempool and fee policies explains why transactions confirm at different speeds.
- SegWit and Lightning Network show how Bitcoin continues to evolve for scalability.
🌱 Reflection
Studying these fundamentals taught me not just how Bitcoin works,
but why it works this way — how every rule, from UTXOs to CSV, builds a secure, decentralized network.
It’s the foundation for my next step: learning about wallet architecture and P2P networking
to strengthen my Rust-based Bitcoin wallet project.
Top comments (0)