Bitcoin Transactions and Structure

• Bitcoin transactions, scripts, applications, blocks, the network, limitations, and improvements are the core topics.

Bitcoin Consensus and Structure

• Bitcoin's consensus mechanism creates an append-only ledger.
• Once data is written, it remains permanently.
• Miners use a consensus protocol to validate transactions.
• Currency incentivizes miners to participate.

Transaction-Based Ledger

• Each transaction updates Alice's balance.
• Transactions include inputs (coins consumed) and outputs (coins created).
• Inputs refer to coins from previous transactions.
• Outputs represent newly created coins.
• Minting new currency involves transactions with no inputs.
• Transactions have unique identifiers, with outputs indexed from 0.
• The entirety of a transaction output must be consumed or none of it, necessitating a change address.
• Alice must send money to herself when paying less than the output's worth.
• If Alice pays 17 bitcoins to Bob from an output worth 25 bitcoins, 8 bitcoins must be sent back to herself.
• Change addresses can be different, but must be owned by the user.

Efficient Transaction Verification

• Look up the referenced transaction output to confirm its value and verify it hasn't been spent.
• Blockchain is scanned between referenced and latest transactions.
• Additional data structures can quicken the process.
• Transactions consist of metadata (size, number of inputs/outputs, transaction ID, lock_time), inputs (previous transaction, output index, signature), and outputs (value, recipient address/script).
• Miners receive transaction fees if total output value is less than the total input value.

Bitcoin Scripts and Conditions for Spending

• Scripts enable the setting of arbitrary conditions to spend coins.
• An address is derived from the hash of a public key.
• Only entire transactions can be signed in Bitcoin.
• scriptPubKey specifies that a public key (hashed to X) along with a signature from the owner of that public key needs to be redeemed.
• scriptSig includes scripts instead of signatures in the inputs.
• Validate a transaction by combining the new transaction's input script and the earlier transaction's output script.
• Bitcoin scripting language is stack-based, not Turing-complete due to no loops, and focused on cryptography.

Applications of Bitcoin Scripts

• Proof-of-burn bootstraps alternatives to Bitcoin or embeds data in the blockchain.
• Pay-to-script-hash (P2SH) is used for MULTISIG addresses or complex spending conditions.
• Alice doesn't want to pay until after shes's received the goods, but Bob doesn't want to send the goods until after he has been paid in Escrow Transactions.
• Green addresses suit situations where immediate payment is impractical for small transactions.
• Micropayments may be used if Bob is Alice's wireless service provider and requires her to pay a small fee for every minute that she talks on her phone.

Bitcoin Block Structure

• Block consists of two hash structure types: hash chain and Merkle Tree
• Blockchain contains a hash chain linking blocks.
• Block also contains a Merkle Tree of transactions.
• Block header contains mining puzzle information, a nonce to change, a timestamp, the difficulty, and the root of the transaction tree using the "mrkl_root" field.

Coinbase Transactions

• Coinbase transactions generate new Bitcoin coins.
• They have a single input and single output.
• The input doesn't redeem a previous output and has a null hash pointer.
• Miner's revenue is the output, halving every 210,000 blocks.
• Value of output is the sum of the mining reward plus transaction fees.

Bitcoin Network Structure

• Bitcoin is a peer-to-peer network using TCP with random topology.
• New nodes can join anytime, but are forgotten after 3 hours of inactivity.
• Joining requires knowing how to contact one node.
• Transactions are published using a flooding algorithm (gossip protocol).
• Latency may cause nodes to have different views of the transaction pool.
• A race condition can occur due to double-spend attempts.
• Winner of the next block essentially break ties.
• New blocks are announced via same logic as transactions.
• Nodes forward blocks only based on the longest branch of the blockchain.
• Average block propagation time in 2013 was 12.6 seconds.

Network Size and Nodes

• Bitcoin network has approximately 16,000 reachable nodes as of February 2025.
• Running a full Bitcoin node requires 600 GB of storage.
• 2 GB of RAM is needed to run a full node.
• Full nodes require entire unspent transaction output storage in RAM.
• Bitcoin network has processed about 1.157 billion transactions as of February 2025 since 2009.
• Bitcoin network maintains around 80 million Unspent Transaction Outputs (UTXOs) as of February 2025.
• Approximately 500,000 transactions are processed daily.

Simplified Payment Verification (SPV) Clients

• Thin nodes are otherwise known as Simple Payment Verification (SPV) clients.
• They store only the necessary pieces to verify specific transactions.
• Block headers are about 1/1,000 the size of the blockchain.
• Bitcoin has approximately 840,000 blocks, and is estimated to be around 67 MB.

Node Requirements (Full vs SPV)

• Full nodes require at least a 1 TB SSD and 4 GB RAM (8 GB+ recommended).
• Intel i5/i7, AMD Ryzen 5/7, or equivalent CPU is require for full nodes.
• Full nodes also needs at least 500 GB/month internet connection with 50 Mbps speed.
• SPV nodes require less than 10 MB for block headers and 512 MB RAM.
• Low-end processors (e.g., Raspberry Pi, smartphones) are acceptable for SPV nodes.
• SPV nodes additionally necessitates ~10 MB/month of internet connection for headers.

Limitations

• Bitcoin protocol constraints are hard-coded.
• Limits address concerns such as; average time per block, block sizes, the number of signature operations in a block, the divisibility of the currency, the total number of Bitcoins, and the block reward structure.
• Bitcoin limit structures are not likely to be changed.
• Blocks are limited to one megabyte and transactions are 250 bytes.
• Each block has a limit of 4,000 transactions.
• Blocks average about every 10 minutes, resulting in about 7 transactions per second.
• Choices of cryptographic algorithms are unchangeable.
• Software upgrade implementation is not a guarantee.

Forks: Hard vs Soft

• A hard fork is when a new version of software considers blocks as valid blocks that the old version would reject.
• Blockchain splits occur when some nodes have been upgraded, but some have not.
• The longest branch contains blocks considered invalid by the old nodes.
• Branches will never re-join when old nodes continue to work on blocks excluding the new feature.
• Adding features that make validation rules stricter is a soft fork.
• Old versions accept all blocks as that the new versions would reject.
• Enforcing new rules occurs with the majority of nodes switch over to new software.
• Examples of soft forks is P2SH.
• A hard fork is a major protocol upgrade that is not backward compatible. Nodes running old software won't recognize transactions/blocks from the new version, thus, leads to a chain split.
• A soft fork is a minor protocol upgrade that is backward compatible. Thus, old nodes would likely consider the new blocks as valid and may be able to enforce the rules.