> For the complete documentation index, see [llms.txt](https://www.notbank.com/learn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.notbank.com/learn/academy/en/bitcoin/block-structure.md). # Block Structure *** > “Miners build blocks, but nodes decide which blocks to follow.”\ > — *Fundamental principle of Bitcoin* *** ## 1. Introduction Bitcoin is a distributed network whose operation depends on two central structures: 1. **blocks** 2. **transactions** Both are chained cryptographically using **Merkle trees** and protected by **Proof of Work (PoW)**.\ Understanding their design is essential to understand: * how information is organized * how incentives work * how immutability is guaranteed * how consensus is reached without a central authority *** ## 2. The blockchain: general structure A Bitcoin block is composed of two main parts: ┌────────────────────┐\ │ Header (80B) │ ← Block hash \ └────────────────────┘\ ┌────────────────────┐\ │ Body: transactions │ \ └────────────────────┘ *** ### 2.1. Header fields The block header is exactly **80 bytes**, structured as follows: | Field | Size | Description | | ----------------- | -------- | -------------------------- | | version | 4 bytes | Indicates validation rules | | prev\_block\_hash | 32 bytes | Previous block hash | | merkle\_root | 32 bytes | Merkle tree root | | timestamp | 4 bytes | Approximate time | | bits | 4 bytes | Difficulty target | | nonce | 4 bytes | Counter for PoW | Final block hash: $$\text{hash\_bloque} = SHA256(SHA256(\text{header}))$$ *** ## 3. Block body: transactions A block contains: * 1 **coinbase transaction** (the first) * N normal transactions Conceptual representation: Block \ ├─ Coinbase TX \ ├─ TX1 \ ├─ TX2\ ├─ ... \ └─ TXn The current limit is a maximum weight of: $$\text{4,000,000 unidades de weight}$$ after the activation of `SegWit (BIP141)`. *** ## 4. Merkle trees in Bitcoin Merkle trees allow: * to prove inclusion of transactions * to reduce the amount of information required for SPV clients * to protect against modifications ### 4.1. Step-by-step construction 1. Take the hash of each transaction:\ $$h\_i = SHA256d(tx\_i)$$ 2. Group pairs and hash them again: $$H\_{i,j} = SHA256d(h\_i || h\_j)$$ 3. Repeat until reaching the root. *** ### 4.2. Representation ``` Merkle Root / \ Hash 0-3 Hash 4-7 / \ / \ Hash 0-1 Hash 2-3 Hash 4-5 Hash 6-7 / \ / \ / \ / \ TX0 TX1 TX2 TX3 TX4 TX5 TX6 TX7 ``` *** ### 4.3. Inclusion proofs (Merkle Proof) An SPV client can prove that: $$tx\_j \in \text{bloque}$$ with a proof of size $$O(\log n)$$. *** ## 5. Bitcoin transactions: technical structure A transaction consists of: * **inputs** (inputs) * **outputs** (outputs) The **inputs** consume previous UTXOs.\ The **outputs** create new UTXOs. *** ### 5.1. General format Transaction \ ├─ Version (4 bytes) \ ├─ TX\_IN\_COUNT \ ├─ \[Inputs] \ ├─ TX\_OUT\_COUNT \ ├─ \[Outputs] \ └─ locktime *** ### 5.2. UTXO: Bitcoin's accounting model Bitcoin does not use accounts.\ It uses a global set of unspent outputs (*Unspent Transaction Outputs*). Advantages: * parallelization * easy verifiability * protection against double spending * simplicity in validation Formalization: $$UTXO\_{new} = UTXO\_{old} - inputs + outputs$$ *** ## 6. Inputs: consuming previous transactions An input contains: | Field | Description | | ----------- | -------------------------------- | | prev\_txid | hash of the previous transaction | | prev\_index | index of the consumed output | | scriptSig | signature + unlocking data | | sequence | used in locktime | The input proves that the user owns the private key associated with the UTXO. *** ### 6.1. scriptSig (classic) Example: ` ` With `SegWit`, the signature goes in a different field (*witness*). *** ## 7. Outputs: creating new UTXOs An output contains: | Field | Description | | ------------ | ------------------- | | value | amount in satoshis | | scriptPubKey | spending conditions | *** ### 7.1. Most common scriptPubKey (P2PKH) `OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG` *** ### 7.2. P2SH Type introduced by BIP16: `OP_HASH160 OP_EQUAL` *** ### 7.3. P2WPKH (SegWit) Witness format: `0 <20-byte-key-hash>` Benefits: * lower signature weight * eliminates malleability * reduces fees *** ## 8. Signatures in transactions Bitcoin uses `ECDSA` over the curve `secp256k1`. To sign a transaction a message is constructed: $$m = \text{serialización modificada}(\text{TX})$$ Then: $$firma = ECDSA\_sign(privkey, m)$$ *** ### 8.1. Sighash types Bitcoin allows different signing modes: | Code | Effect | | --------------- | ------------------------------ | | SIGHASH\_ALL | Signs inputs and outputs | | SIGHASH\_NONE | Signs inputs, outputs are free | | SIGHASH\_SINGLE | Signs the corresponding input | | ANYONECANPAY | Modifies allowed inputs | *** ## 9. The coinbase transaction It is the first transaction in each block. ### 9.1. Features: * it has no valid inputs * it creates new bitcoins * includes the reward (subsidy + fees) * contains an **arbitrary script** with optional messages Classic example: the genesis block's message. *** ### 9.2. Subsidy $$\text{Subsidio actual} = 50 \cdot 2^{-n}$$ where * $$n$$ = number of halvings that have occurred *** ## 10. How transactions are verified A node verifies: 1. **Correct format** 2. **Valid signatures** 3. **UTXOs exist** 4. **No double spending** 5. **Outputs do not exceed inputs** 6. **Valid sighash** 7. **Script executed without error** *** ### 10.1. Script evaluation Bitcoin Script is a simple, non-Turing-complete language. Evaluation example `P2PKH`: scriptSig: ` `\ scriptPub: `OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG` *** ## 11. Block validation To accept a block: 1. Block hash < Target 2. All transactions valid 3. Correct size 4. Correct reward 5. Prev\_block\_hash matches 6. The Merkle Root matches 7. Reasonable timestamp *** ## 12. Mathematical representation of the chaining If: * $$B\_i$$ = Block i * $$H(B\_i)$$ = Hash of block i header then: $$\text{prev\_hash}(B\_i) = H(B\_{i-1})$$ which produces: $$B\_0 \rightarrow B\_1 \rightarrow B\_2 \rightarrow \dots$$ Security depends on: $$\text{Costo de reorganización} \approx \text{PoW acumulado}$$ *** ## 13. Chapter conclusion In this chapter we have seen: * how a block is structured * how transactions are organized and verified * what role the Merkle tree plays * how the integrity of the chain is ensured * why the UTXO system is superior to an account-based model All these elements are the basis of Bitcoin's fundamental layer. *** > If you understand a block, you understand Bitcoin.\ > If you understand the Merkle tree, you understand why it is immutable. *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://www.notbank.com/learn/academy/en/bitcoin/block-structure.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.