Bitcoin Nodes and Network

Section VI: Bitcoin Framework

Army Cyber Institute

April 9, 2026

Bitcoin’s Peer-to-Peer Network

• Architecture: a fully decentralized network where nodes connect directly to one another—no central servers or coordinators.
  
• Connectivity: each node discovers peers dynamically and maintains multiple simultaneous connections for redundancy and robustness.
  
• Roles within the network:
  • Full nodes: validate blocks and transactions, and relay data to peers.
    
  • Miners: perform Proof-of-Work and extend the blockchain with new blocks.
    
  • SPV (light) clients: verify transactions using block headers and Merkle proofs without storing full data.
    
• Goal: achieve global resilience, censorship resistance, and permissionless participation through replication and independent validation.

Overall Slide Concept This opening slide establishes Bitcoin’s peer-to-peer network as the infrastructure that lets independent validators, miners, and light clients coordinate without a central server. It matters here because the lesson is shifting from transactions and mining mechanics to the communication fabric that carries those actions across the system. Emphasize that resilience and trust minimization come from replication and independent validation rather than from any central coordinator.

Key Points - Bitcoin uses a decentralized peer-to-peer network rather than a central hub. - Full nodes, miners, and light clients play different roles within that network. - The network’s purpose is resilient relay, independent verification, and permissionless participation.

Walkthrough None

Sources - [1] - [2]

Elements of the Bitcoin Network

• Scale: typically ~10,000 publicly reachable nodes worldwide (exact count fluctuates over time).
  
• Connectivity: each node maintains multiple outbound and inbound peer connections to ensure redundancy and fast data propagation.
  
• Core network functions:
  • Transaction relay: broadcasting and verifying unconfirmed transactions.
    
  • Block propagation: distributing newly mined blocks across the network.
    
  • Peer discovery: finding and maintaining new connections dynamically.
    
• Incentive and resilience: the network’s health depends on broad, independent participation—more nodes mean greater redundancy, decentralization, and censorship resistance.

Overall Slide Concept This slide establishes the Bitcoin network as a large, dynamic graph of reachable and hidden participants exchanging transactions, blocks, and peer information. It matters here because students should see that network health depends on connectivity patterns and broad participation, not just on protocol rules. Emphasize that node count and connection diversity contribute directly to resilience and censorship resistance.

Key Points - The public network includes thousands of reachable nodes, plus many more behind NAT or firewalls. - Nodes maintain multiple connections to support redundancy and fast relay. - Transaction relay, block propagation, and peer discovery are the network’s core recurring functions.

Walkthrough None

Sources - [3]

What Is a Bitcoin Node?

• Definition: a node is any computer running Bitcoin software that participates directly in the peer-to-peer network.
• Its Core functions include:
  • Validation: checks the correctness of transactions and blocks against consensus rules.
    
  • Relay: shares verified information with connected peers to keep the network synchronized.
    
  • Storage: maintains a local copy (full or partial) of the blockchain ledger.

Why it matters: nodes are the distributed record—without them, there is no independent verification or decentralized consensus.

Overall Slide Concept This slide establishes what a Bitcoin node actually is: software that validates, relays, and stores ledger data as part of the peer-to-peer network. It matters here because students often confuse miners with nodes or treat nodes as passive data copies rather than as active rule enforcers. Emphasize that miners propose blocks, but nodes decide whether those proposals are valid.

Key Points - A node is any computer running Bitcoin software that participates directly in the network. - Nodes validate transactions and blocks, relay accepted data, and store blockchain information. - Without independent nodes, decentralized consensus has no practical enforcement layer.

Walkthrough None

Sources - [2] - [4]

Types of Nodes

• Full nodes:
  • Store the entire blockchain history.
    
  • Independently validate every transaction and consensus rule.
    
  • Form the backbone of network integrity and decentralization.
• Light clients (SPV):
  • Download only block headers instead of full blocks.
    
  • Verify transactions using Merkle proofs provided by full nodes.
    
  • Trade some independence for lower bandwidth and storage needs.
• Core trade-off: full validation offers maximum trustlessness, while lightweight clients prioritize accessibility and efficiency.

Overall Slide Concept This slide establishes the trust trade-off between full validation and lightweight participation. It matters here because students need to understand why full nodes anchor Bitcoin’s security model while SPV clients make Bitcoin accessible on constrained devices. Emphasize that convenience and bandwidth savings come at the cost of reduced independence.

Key Points - Full nodes store and validate the entire chain and all consensus rules. - Light clients verify inclusion using headers and proofs rather than full validation. - The core trade-off is independence versus efficiency.

Walkthrough None

Sources - [1] - [2] - [5]

Why Run a Node?

• Security: Verify transactions without trusting others.
• Privacy: Directly query blockchain data.
• Decentralization: More nodes, stronger network.
• Control: Enforce Bitcoin’s consensus rules locally, so your node only accepts blocks and transactions that match the version of Bitcoin you choose to run.

Overall Slide Concept This slide establishes why someone would run a node even without mining: to verify personally, preserve privacy, and strengthen the network’s decentralization. It matters here because the lesson is connecting network participation to both ideology and operational security. Emphasize that running a node lets a user enforce Bitcoin’s rules locally instead of outsourcing trust.

Key Points - Running a node supports “don’t trust, verify” by removing reliance on third-party infrastructure. - A personal node can reduce privacy leakage from address and transaction queries. - More independent nodes make censorship and centralization harder.

Walkthrough None

Sources - [1] - [6] - [4]

Setting Up a Full Node

• Install: download and run Bitcoin Core, the open-source reference implementation.
  
• Requirements:
  • Disk space: 600+ GB (growing).
  • Stable internet connection.
  • Regular updates to keep consensus rules current.
• Initial block download can take days.

Overall Slide Concept This slide establishes what is required to operate a full validating node in practice. It matters here because students should see that independence has real storage, bandwidth, and time costs, especially during initial block download. Emphasize that the resource burden is the price paid for complete local verification.

Key Points - Bitcoin Core is the reference implementation most users rely on for full-node operation. - Full nodes require substantial disk space, stable connectivity, and ongoing maintenance. - Initial block download is slow because the node verifies history from genesis rather than trusting a shortcut.

Walkthrough None

Sources - [7] - [6]

Setting Up a Light Client

• Deployment: typically built into mobile or desktop wallets for quick setup and low resource use.
  
• Simplified Payment Verification (SPV):
  • Downloads only block headers, not full blocks.
    
  • Requests Merkle proofs from connected full nodes to verify specific transactions.
    
• Trade-off: lightweight and fast to sync, but shifts trust toward the full nodes it connects to and assumes they are honest and well-connected.

Overall Slide Concept This slide establishes light clients as the practical alternative for users who want Bitcoin access without running a full node. It matters here because most real-world wallet users interact through lightweight verification models rather than through full-chain validation. Emphasize that SPV improves usability, but it shifts some trust back toward full nodes and peer selection.

Key Points - Light clients download only block headers and request proofs for relevant transactions. - SPV makes mobile and low-resource wallets practical. - The trade-off is reduced independence and greater exposure to dishonest or poorly connected peers.

Walkthrough None

Sources - [6]

Joining the Bitcoin Network

• Peer-to-peer architecture: nodes connect directly without central coordination.
  
• Outbound connections: by default, a node initiates ~8 outbound TCP connections to maintain healthy network gossip and redundancy.
  
• Peer discovery:
  • Uses DNS seeds (publicly maintained domain names) that return IPs of reachable nodes.
    
  • May also use hardcoded “fallback” peers or address gossip from other nodes once connected.

Goal: ensure that every honest node can find and maintain diverse peers for transaction relay, block propagation, and consensus updates.

Overall Slide Concept This slide establishes how a new node bootstraps into a decentralized network without a central peer directory. It matters here because peer discovery is a precondition for all later relay and validation behavior. Emphasize that DNS seeds and fallback peers are startup aids, while ongoing peer exchange sustains the mesh afterward.

Key Points - New nodes begin with DNS seeds, fallback peers, and then transition to address gossip from connected peers. - Default outbound connections are designed to create a healthy initial view of the network. - Peer discovery is decentralized after bootstrap, even though a few helper mechanisms exist at startup.

Walkthrough None

Sources - [2] - [8]

Node Operator Responsibilities

• Maintain consensus: keep node software updated and aligned with the latest consensus rules.
  
• Policy decisions:
  • Choose which implementation or version of Bitcoin to run—especially relevant during forks or upgrades.
    
  • Configure peer connections, including optional blocklists, whitelists, and connection limits.
    
• Economic influence: nodes operated by exchanges, merchants, custodians, and mining pools carry greater weight in practice, since their policy choices affect which rules and transactions the wider ecosystem recognizes.
  
• Stewardship role: running a node is both a technical and civic act—operators collectively define the active consensus of the network.

Overall Slide Concept This slide establishes node operation as an active governance role rather than a passive background service. It matters here because node operators influence consensus outcomes through software version choice, peer configuration, and the economic weight attached to their services. Emphasize that Bitcoin governance emerges through voluntary coordination among many validating actors.

Key Points - Node operators choose what software and rules they are willing to enforce. - Configuration choices around peers and policies shape how a node participates in the wider network. - Economically important nodes can have outsized influence during upgrades and disputes.

Walkthrough None

Sources - [6] - [9]

Decisions Nodes Make

• Consensus rules: choose which version of the protocol to enforce—determining which blocks and transactions are considered valid.
  
• Relay policy: set minimum transaction fees, rate limits, or filters that shape what data the node will forward to peers.
  
• Network management: select and manage peers, blocking spammy or malicious nodes while prioritizing reliable connections.
  
• Principle: each node is a sovereign participant—it independently enforces the rules it accepts, forming consensus through voluntary coordination, not central command.

Overall Slide Concept This slide establishes the difference between consensus decisions and policy decisions made by nodes. It matters here because students need to understand that not every relay choice is a validity rule, even though both affect network behavior. Emphasize that Bitcoin’s decentralized governance comes from many nodes independently enforcing the rules they accept.

Key Points - Consensus rules determine validity, while policy rules shape relay and mempool behavior. - Nodes also manage peers to improve reliability and reduce exposure to abuse. - Emergent network behavior comes from many independent nodes making these decisions locally.

Walkthrough None

Sources - [6] - [10] - [2] - [9]

Gossip and Peer Connections

• After bootstrap: each node learns about new peers through a gossip protocol—nodes share information about other reachable nodes.
  
• Address exchange: addr and addrv2 messages advertise known peers, allowing the network to expand organically without a central directory.
  
• Connectivity pattern: each node maintains roughly 8 outbound and a variable number of inbound connections, forming a constantly shifting mesh topology.
  
• Dynamic behavior: peers are periodically dropped, replaced, or added—promoting redundancy, fault tolerance, and resistance to partitioning or isolation attacks.

Overall Slide Concept This slide establishes how nodes expand their network view after initial bootstrap through address gossip and changing peer sets. It matters here because the network’s resilience depends on dynamic connectivity rather than on fixed topologies. Emphasize that peer churn and multiple connection types make long-term isolation harder.

Key Points - Nodes learn about additional peers through addr and addrv2 messages. - Typical nodes keep multiple outbound and inbound links to avoid brittle dependence on a few peers. - Rotating peers over time improves freshness and resistance to eclipse-style attacks.

Walkthrough None

Sources - [1] - [2]

Communication Protocol Basics

• Transport layer: nodes communicate over long-lived TCP connections, exchanging structured messages in both directions.
  
• Message types: the Bitcoin protocol defines around 30 core message commands—examples include version, verack, inv, getdata, tx, and block.
  
• Message format:
  • Header: contains the command name, payload length, and checksum for integrity verification.
    
  • Payload: carries the message-specific data (e.g., transaction contents or block headers).
    
• Design goal: minimize overhead while ensuring reliable propagation of transactions, blocks, and peer information across a global network.

Overall Slide Concept This slide establishes the low-level communication format that lets Bitcoin nodes exchange information reliably across the Internet. It matters here because block and transaction relay depend on structured, predictable messages over long-lived connections. Emphasize that compact message headers and specific command types make the network’s “plumbing” efficient and verifiable.

Key Points - Bitcoin nodes communicate over TCP using a defined set of message commands. - Each message has a header describing the payload and a payload carrying the actual data. - Efficient message design helps the network propagate data quickly without unnecessary overhead.

Walkthrough None

Sources - [1] - [2]

Transaction Relay

• Announcement: when a node receives a new transaction, it advertises it to peers using an inv (inventory) message.
  
• Request: peers that don’t already have the transaction respond with a getdata message requesting the full data.
  
• Transmission: the originating node then sends the complete transaction using a tx message.
  
• Goal: efficient, bandwidth-aware propagation—nodes announce first, then only transmit when requested.

Overall Slide Concept This slide establishes the announce-request-transmit pattern that Bitcoin uses to relay transactions without flooding the network. It matters here because efficient transaction propagation is a prerequisite for good mempool synchronization and later block assembly. Emphasize that propagation does not equal confirmation; it only ensures data reaches peers that may want it.

Key Points - Nodes advertise new transactions with inv, respond to requests with getdata, and then send the transaction with tx. - This pattern saves bandwidth because full data is sent only to peers that need it. - Efficient relay helps transactions reach miners and validating peers quickly.

Walkthrough None

Sources - [1] - [2]

Block Propagation

• Process: block relay follows the same announce–request–transmit pattern as transactions: inv → getdata → block.
  
• Efficiency improvement: the compact block relay protocol minimizes bandwidth use by sending:
  • Short transaction IDs for transactions peers likely already have.
    
  • Only full transactions if the peer’s mempool is missing them.
    
• Goal: achieve rapid, global block propagation to keep miners in sync and reduce the risk of competing forks.

Overall Slide Concept This slide establishes how block relay extends the same announce-request logic while adding compact block optimizations for speed. It matters here because fast block propagation reduces stale-block risk and keeps miners working on the same chain tip. Emphasize that bandwidth efficiency is a consensus-security issue because slower propagation increases the chance of competing tips.

Key Points - Blocks are announced, requested, and relayed much like transactions. - Compact block relay sends short transaction IDs when peers likely already have the underlying transactions. - Faster propagation lowers wasted work and reduces the chance of competing forks.

Walkthrough None

Sources - [11] - [2]

Fault Tolerance

• Redundant connectivity: each node maintains multiple inbound and outbound links, so losing a few peers does not disconnect it from the network.
  
• Gossip resilience: Bitcoin’s peer-to-peer gossip protocol ensures that transactions and blocks eventually reach the entire network, even when some links fail.
  
• Potential threats:
  • Eclipse attacks: an adversary surrounds and isolates a node, controlling all its connections.
    
  • Partitioning attacks: attempt to split the network into disconnected regions to delay consensus or block propagation.
    
• Mitigation: peer and route diversity, rotating connections, and independent discovery methods make large-scale isolation difficult and improve overall network robustness.

Overall Slide Concept This slide establishes that Bitcoin’s network robustness depends on redundant connectivity and broad participant diversity, not on perfect links. It matters here because students should see eclipse and partitioning attacks as attacks on visibility and timing rather than on signatures or validity rules. Emphasize that resilience comes from many independent routes and changing peer relationships.

Key Points - Multiple connections and redundant gossip paths prevent minor failures from isolating a node. - Eclipse and partitioning attacks target a node’s or region’s network view rather than Bitcoin’s cryptography. - Diverse peers, routes, and rotation make those attacks harder and improve overall robustness.

Walkthrough None

Sources - [12] - [8] - [4] - [2]

Network Growth and Concerns

• Dynamic participation: the number of reachable nodes fluctuates over time as hardware costs, energy prices, and incentives influence who runs infrastructure.
  
• Resource demands: as the blockchain grows, running a full node requires increasing storage, bandwidth, and processing power—raising the barrier to entry.
  
• Centralization pressures:
  • Mining concentration: large mining pools dominate block production due to economies of scale.
    
  • Node consolidation: fewer independently operated full nodes reduce network diversity and resilience.
    
• Design tension: achieving scalability often increases efficiency at the expense of decentralization—balancing the two is an ongoing challenge.

Overall Slide Concept This slide establishes the long-run pressures that can make a decentralized network harder to sustain as usage and costs rise. It matters here because students need to see that decentralization is an ongoing economic balance, not a one-time design achievement. Emphasize the tension between capacity, operator diversity, and the incentives that shape both nodes and miners.

Key Points - Node counts and reachable participation fluctuate with costs and incentives. - Growing storage, bandwidth, and mining specialization can raise barriers to entry. - Bitcoin continually balances scalability pressures against decentralization goals.

Walkthrough None

Sources - [1] - [6]

Introduction to Bitcoin Script

• Purpose: Bitcoin transactions use a stack-based scripting language to specify the exact conditions required to spend each output (UTXO).
  
• Functionality: scripts are executed and validated by nodes—if the conditions evaluate to “true,” the spend is accepted.
  
• Design: intentionally not Turing-complete to avoid loops, reduce complexity, and prioritize safety and determinism.
  
• Heritage: part of Bitcoin’s design since the Genesis Block—enabling programmable spending rules long before smart contracts became a broader concept.

Overall Slide Concept This slide establishes Bitcoin Script as the mechanism that turns UTXOs into programmable spending conditions. It matters here because the lesson is shifting from network transport into the rule language that nodes evaluate when a spend is attempted. Emphasize that Script supports conditional payments while remaining deliberately constrained for safety and determinism.

Key Points - Bitcoin Script is a stack-based language used to define spending conditions for outputs. - Nodes validate script execution when an output is spent. - Script is intentionally not Turing-complete to keep behavior bounded and predictable.

Walkthrough None

Sources - [1] - [13]

Why Bitcoin Script Exists

• Original vision: allow transactions to include flexible spending conditions such as multi-signature authorization, time locks, and other constraints.
  
• Purpose: make money programmable without requiring a central authority—rules are enforced by consensus, not trust.
  
• Role in the system: serves as the foundation for advanced transaction types and later contract layers (e.g., Lightning, sidechains).
  
• Example: a time-locked output prevents spending until a specified block height or timestamp is reached.
  
• Enforcement: full nodes validate these conditions automatically when a spend is attempted, ensuring deterministic and decentralized rule execution.

Overall Slide Concept This slide establishes why Script exists at all: to make money programmable without introducing a trusted intermediary or a general-purpose virtual machine. It matters here because students should see advanced spending conditions as part of Bitcoin’s original design, not as an afterthought. Emphasize that full nodes enforce these conditions automatically when a spend is attempted.

Key Points - Script allows conditions like multisig and time locks to be enforced by the network. - The rules are checked at spend time rather than by a central administrator. - Script gives Bitcoin limited programmability while preserving safety and consensus clarity.

Walkthrough None

Sources - [1] - [13]

Bitcoin Script Basics

• Two components of a Bitcoin transaction input/output pair:
  • scriptPubKey (locking script): defines the spending conditions for a UTXO—what must be provided to unlock it.
    
  • scriptSig (unlocking script): provides the data (e.g., signature, public key) needed to satisfy those conditions.
    
• Example: Pay-to-PubKey-Hash (P2PKH) — the most common script type.
  • The locking script requires a signature matching a specific public key hash.
    
  • The unlocking script supplies that signature and corresponding public key.
    
• Execution model: nodes concatenate both scripts and evaluate them on a stack; if the result is TRUE, the spend is valid.

Overall Slide Concept This slide establishes the two-part structure of a scripted Bitcoin spend: the locking script on the UTXO and the unlocking data provided by the spender. It matters here because students need a simple mental model before the lesson introduces specific opcodes and P2PKH evaluation. Emphasize that validity comes from evaluating both parts together on a stack.

Key Points - scriptPubKey encodes the conditions attached to an output. - scriptSig provides the data needed to satisfy those conditions. - A spend is valid only if the combined script execution leaves a true result.

Walkthrough None

Sources - [1] - [13] - [10]

Script Primitives

• Cryptographic operations:
  • OP_CHECKSIG — verifies a single digital signature.
    
  • OP_CHECKMULTISIG — validates multiple signatures against a set of public keys.
• Hashing operations:
  • OP_HASH160 — applies SHA-256 followed by RIPEMD-160 (used in P2PKH).
    
  • OP_SHA256 — computes a standard SHA-256 hash.
• Time-based constraints:
  • OP_CHECKLOCKTIMEVERIFY — prevents spending until a specified block height or timestamp.
    
  • OP_CHECKSEQUENCEVERIFY — enforces relative time locks between transactions.
• Control flow:
  • OP_IF, OP_ELSE, OP_ENDIF — conditional logic to enable script branches.
• Data operations:
  • Push, duplicate (OP_DUP), and compare values on the stack.

Overall Slide Concept This slide establishes Script as a toolbox of small opcodes that can be combined into useful but bounded spending rules. It matters here because it shows how Bitcoin achieves flexibility without adopting unbounded computation. Emphasize the categories of operations rather than memorizing every opcode in isolation.

Key Points - Script includes cryptographic, hashing, time-lock, control-flow, and data-manipulation operations. - These primitives support multisig, conditional payments, and delayed spending. - The limited opcode set reflects Bitcoin’s preference for safety and predictable validation.

Walkthrough None

Sources - [14] - [15]

Example: Pay-to-PubKey-Hash (P2PKH)

• Overview: the most common and foundational Bitcoin script type—used in standard single-signature payments.

• Locking script (scriptPubKey):

  OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

• Unlocking script (scriptSig):

  <signature> <pubKey>

• Meaning:

  • The spender must provide a public key whose hash matches <pubKeyHash>.
  • The provided signature must correctly verify against that public key.

• Execution flow:

  1. The unlocking data is pushed to the stack.
  2. The locking script runs its operations on the same stack.
  3. If the final result evaluates to TRUE, the spend is valid.

Overall Slide Concept This slide establishes P2PKH as the canonical example of how Bitcoin Script enforces ownership with hashes and signatures. It matters here because it makes the abstract locking/unlocking model concrete using the most recognizable standard payment pattern. Emphasize the step-by-step check: matching the public key hash first, then verifying the signature.

Key Points - P2PKH requires the spender to reveal a public key matching the locked hash. - The spender must also provide a valid signature for the transaction. - This example shows how a small set of opcodes can enforce strong cryptographic conditions.

Walkthrough 1. Push the unlocking data, the signature and public key, onto the stack. 2. Run the locking script to duplicate and hash the provided public key, then compare it to the expected hash. 3. Finish with OP_CHECKSIG to verify the signature and accept the spend only if all checks pass.

Sources - [1] - [10] - [13]

Summary

• Nodes: full nodes independently validate and store the entire blockchain; light clients rely on simplified proofs and full nodes for verification.
  
• Network: a decentralized peer-to-peer system using gossip-based communication and redundant connections for resilience and fault tolerance.
  
• Bitcoin Script: a stack-based, purpose-built scripting language that enables conditional spending without the risks of general-purpose computation.
  
• Design constraints: no loops or unbounded logic—prioritizing determinism, auditability, and security over flexibility.
  
• Big picture: Bitcoin’s architecture reflects a deliberate trade-off: security and simplicity take precedence over expressiveness and speed.

Overall Slide Concept This closing slide establishes the lesson’s integrated picture: nodes enforce rules, the peer-to-peer network moves data, and Script defines spend conditions under tight safety constraints. It matters here because students should leave understanding how Bitcoin’s communication layer and validation layer support one another. Emphasize that Bitcoin consistently favors decentralization, auditability, and predictability over maximum expressiveness.

Key Points - Full nodes anchor trust by validating independently, while light clients trade some independence for efficiency. - Gossip and redundant connections keep the network resilient and synchronized. - Script adds programmable spending, but only within carefully bounded limits.

Walkthrough None

Sources - [1] - [6] - [13]

References

[1]

S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System.” Satoshi Nakamoto Institute, Oct. 31, 2008. Accessed: Sep. 12, 2025. [Online]. Available: https://cdn.nakamotoinstitute.org/docs/bitcoin.pdf

[2]

Bitcoin.org Developers, “P2P Network (Developer Guide).” 2024. Available: https://developer.bitcoin.org/devguide/p2p_network.html

[3]

The Bitnodes Project, “Reachable Bitcoin Nodes - Bitnodes.” Accessed: Oct. 27, 2025. [Online]. Available: https://bitnodes.io/

[4]

A. M. Antonopoulos, Mastering Bitcoin: Programming the open blockchain, Second edition. Sebastopol, CA: O’Reilly, 2017.

[5]

J. Risson and T. Moors, “Survey of Research towards Robust Peer-to-Peer Networks,” University of New South Wales, Sydney, Australia, Technical UNSW-EE-P2P-1-1, Sep. 2004. Available: https://www.cs.umd.edu/projects/p2prg/p2p-overview.pdf

[6]

Bitcoin.org Developers, “Operating Modes (Developer Guide).” 2024. Available: https://developer.bitcoin.org/devguide/operating_modes.html

[7]

Bitcoin.org Developers, “Block Chain (Developer Guide).” 2024. Available: https://developer.bitcoin.org/devguide/block_chain.html

[8]

C. Decker and R. Wattenhofer, “Information propagation in the Bitcoin network,” in IEEE P2P 2013 Proceedings, 2013, pp. 1–10. doi: 10.1109/P2P.2013.6688704.

[9]

A. Narayanan, J. Bonneau, E. Felten, A. Miller, and S. Goldfeder, Bitcoin and Cryptocurrency Technologies. Princeton University Press, 2016.

[10]

Bitcoin.org Developers, “Transactions (Developer Guide).” 2024. Available: https://developer.bitcoin.org/devguide/transactions.html

[11]

M. Corallo, “BIP 152: Compact Block Relay.” Accessed: Oct. 27, 2025. [Online]. Available: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki

[12]

M. Apostolaki, A. Zohar, and L. Vanbever, “Hijacking Bitcoin: Routing Attacks on Cryptocurrencies,” in 2017 IEEE Symposium on Security and Privacy (SP), May 2017, pp. 375–392. doi: 10.1109/SP.2017.29.

[13]

Bitcoin.org Developers, “Contracts (Bitcoin Developer Guide).” 2024. Available: https://developer.bitcoin.org/devguide/contracts.html

[14]

P. Todd, “BIP 65: OP_CHECKLOCKTIMEVERIFY.” Accessed: Oct. 27, 2025. [Online]. Available: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

[15]

BtcDrak, M. Friedenbach, and E. Lombrozo, “BIP 112: CHECKSEQUENCEVERIFY.” Accessed: Oct. 27, 2025. [Online]. Available: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki