Unit 4: Bitcoin Network, Payments, Clients and APIs - Subjective Questions

The Bitcoin network is a decentralized peer-to-peer network in which nodes communicate without relying on a central server.

• Peer discovery: A new node discovers peers using DNS seeds, previously stored peer addresses, or addresses received from other nodes.
• Node connections: Nodes establish outbound and inbound TCP connections and exchange protocol-version information.
• Transaction relay: A valid transaction is announced to peers, which independently validate it before forwarding it.
• Block relay: Miners create blocks and broadcast them. Nodes verify each block's proof of work, transactions, size, and consensus rules.
• Distributed ledger: Full nodes maintain their own copy of the blockchain and independently determine the valid chain with the greatest cumulative proof of work.
• Decentralization: No node has authority over another. Consensus emerges because nodes enforce the same protocol rules.

This architecture provides fault tolerance, censorship resistance, and transparency, although network delays may temporarily cause nodes to have different views of unconfirmed transactions or the blockchain tip.

A Bitcoin transaction passes through the following stages:

1. Creation and signing: A wallet selects unspent transaction outputs, creates outputs for the recipients and change, and signs the inputs with the appropriate private keys.
2. Broadcasting: The wallet sends the transaction to one or more Bitcoin nodes.
3. Node validation: Each receiving node checks the transaction syntax, signatures, referenced UTXOs, scripts, amount limits, and absence of double spending.
4. Mempool entry: If valid under consensus and node policy rules, the transaction is placed in the node's mempool.
5. Relay: The node announces the transaction to its peers, allowing it to spread throughout the network.
6. Mining: A miner selects transactions, usually considering fee rate, and includes them in a candidate block.
7. Block confirmation: Once the block is accepted, the transaction has one confirmation. Every additional block increases its confirmation count.

Confirmations reduce reversal risk because replacing a confirmed transaction requires recreating the proof of work of its block and all subsequent blocks.

A Bitcoin wallet is a tool that manages keys, constructs transactions, signs payments, and displays balances derived from blockchain data. Bitcoins are not physically stored in the wallet; control is represented by possession of the relevant private keys.

• Software wallet: Runs on a computer or phone. It is convenient but may be exposed to malware or device compromise.
• Hardware wallet: Stores private keys in a dedicated device and signs transactions internally. It offers strong protection against online attacks.
• Paper wallet: Records a private key or seed on paper. It is offline but is vulnerable to physical loss, damage, insecure generation, and operational mistakes.
• Custodial wallet: A service controls the private keys on the user's behalf. It is easy to use but introduces counterparty, freezing, and insolvency risks.
• Watch-only wallet: Contains public keys or addresses but no private keys. It can monitor balances and create unsigned transactions but cannot spend funds.

For long-term storage, a hardware wallet with securely backed-up recovery information is generally safer than an internet-connected or custodial wallet.

A deterministic wallet derives many private keys from one master secret. A hierarchical deterministic wallet, commonly called an HD wallet, organizes these keys into a tree of accounts, branches, and addresses.

Key features include:

• A single random seed can deterministically recreate all derived keys.
• Child keys can be organized by purpose, coin type, account, change branch, and address index.
• Extended public keys can generate public addresses without exposing private keys, which is useful for watch-only systems.
• A wallet can generate a new receiving address for each payment, improving privacy and accounting.

A seed phrase is a human-readable encoding associated with the wallet's seed. A secure backup is critical because loss of the seed and signing devices may make funds permanently inaccessible. The seed should be recorded offline, verified, protected from fire and theft, and never shared. Anyone who obtains it can usually reconstruct the wallet and spend its funds. A passphrase may add protection, but forgetting it can also cause permanent loss.

A typical Bitcoin payment proceeds as follows:

1. The receiver generates a fresh address or payment request and communicates it to the payer.
2. The payer's wallet validates the address or invoice and determines the amount.
3. The wallet selects suitable UTXOs as transaction inputs.
4. It creates an output for the receiver and, when necessary, a change output back to the payer.
5. The wallet estimates an appropriate fee according to transaction size and desired confirmation speed.
6. The transaction inputs are authorized using digital signatures or other required witness data.
7. The signed transaction is broadcast to the network.
8. Nodes validate and relay it, while the receiver may detect it as an unconfirmed payment.
9. A miner includes the transaction in a block, producing the first confirmation.
10. The receiver waits for a suitable number of confirmations based on the payment value and risk.

The receiver should verify the amount, destination, confirmation status, and possible conflicts rather than trusting a screenshot or a transaction identifier supplied by the payer.

Bitcoin uses the UTXO model, so a transaction consumes existing outputs and creates new outputs. The basic value relationship is:

If a payer selects inputs worth BTC, sends BTC, and explicitly pays a fee of BTC, the change is:

The transaction normally contains a recipient output and a change output. Any input value not assigned to an output becomes the miner fee.

Fees are usually estimated from the transaction's virtual size, not directly from the amount transferred:

A transaction with many inputs is generally larger and more expensive than one with fewer inputs. Script type, witness data, and number of outputs also affect virtual size. Wallets therefore perform coin selection and fee estimation to balance cost, confirmation speed, privacy, and avoidance of uneconomical change.

Bitcoin payment information can be represented in several ways:

• Address: Encodes a destination associated with a locking condition. Users should verify the network and address carefully because blockchain payments are generally irreversible.
• Payment URI: A URI can combine an address with fields such as amount and label. For example, a wallet may interpret a bitcoin: URI and prefill payment details.
• QR code: Encodes an address or payment URI for convenient scanning. It reduces typing errors but can still be replaced by malware or a fraudulent sticker.
• Invoice: May specify the amount, description, expiration, payment network, and recipient details. Lightning invoices additionally contain information needed to route an off-chain payment.

Good payment practice includes generating a new address or invoice for each customer, validating the amount and network, displaying human-readable confirmation details, and checking the transaction independently. Users should not assume that scanning a QR code makes the destination trustworthy.

These innovations improve different aspects of Bitcoin:

• Segregated Witness: Separates signature-related witness data from the traditional transaction structure. It fixes practical transaction malleability issues, introduces block-weight accounting, improves capacity efficiency, and enables more reliable second-layer protocols.
• Lightning Network: Uses payment channels to conduct many payments off-chain. Only channel-related settlement transactions need to appear on the blockchain. It supports rapid, low-fee payments but introduces channel liquidity, routing, availability, and backup considerations.
• Taproot: Combines Schnorr signatures with improved script commitments. Simple spends and some complex contract spends can appear more similar, while unused spending conditions do not need to be revealed. It can improve privacy, efficiency, and flexibility for multisignature and advanced scripts.

Together, these developments demonstrate Bitcoin's layered evolution: the base layer emphasizes secure settlement, while protocol improvements and secondary layers add efficiency, programmability, and payment scalability.

Advanced Bitcoin protocols combine cryptographic authorization with transaction conditions:

• Multisignature: Requires a threshold of authorized keys, such as two keys out of three, to approve spending. It is useful for shared custody, organizational funds, and recovery arrangements.
• Timelocks: Prevent spending until a specified block height, time, or relative delay has passed. They support delayed recovery paths and protocol-enforced waiting periods.
• Payment channels: Participants lock funds in an on-chain transaction and exchange updated commitments off-chain. The final state can later be settled on the blockchain.
• Hashed timelock contracts: Combine a secret hash condition with a refund timeout. Knowledge of a secret enables one spending path, while expiration enables another.
• Atomic swaps: Coordinate exchanges across compatible blockchains or systems so that either both transfers complete or both parties can recover their funds.

These protocols reduce reliance on trusted intermediaries, but their security depends on correct script construction, safe key management, transaction monitoring, timeout selection, and reliable software.

Bitcoin may be considered an investment because of its limited issuance schedule, global transferability, liquidity, and independence from any single issuer. However, it is highly speculative and does not guarantee returns.

Major risks include:

• Price volatility: Market value can change sharply within a short period.
• Custody risk: Lost keys, phishing, malware, or failed backups can cause irreversible loss.
• Counterparty risk: Exchanges and custodians may be hacked, become insolvent, or freeze withdrawals.
• Regulatory and tax risk: Rules differ across jurisdictions and may change.
• Market risk: Liquidity, leverage, manipulation, and sentiment can affect prices.
• Technical risk: Software bugs, user mistakes, and protocol misunderstandings may cause loss.

Risk-management measures include investing only an affordable amount, avoiding excessive leverage, diversifying, using reputable platforms, withdrawing long-term holdings to secure self-custody when appropriate, testing backups, enabling strong authentication, and maintaining transaction records for tax reporting. Bitcoin should not be described as a guaranteed profit or risk-free store of value.

Buying or selling through an exchange typically involves:

1. Selecting a reputable exchange available in the user's jurisdiction.
2. Creating an account and completing any required identity verification.
3. Enabling strong authentication, preferably using an authenticator or security key rather than relying only on SMS.
4. Depositing fiat currency or Bitcoin using supported methods.
5. Choosing an order type, such as a market order or limit order.
6. Reviewing the price, spread, trading fee, deposit fee, and withdrawal fee.
7. Executing the order and verifying the resulting balance.
8. Withdrawing long-term Bitcoin holdings to a verified self-custody address when suitable.

When selling, the user deposits Bitcoin, waits for required confirmations, places a sell order, and withdraws the resulting fiat balance. Important precautions include testing new withdrawal addresses with a small amount, verifying the network, avoiding phishing links, checking withdrawal limits, understanding tax obligations, and never sharing seed phrases or private keys with an exchange or support agent.

The main methods differ in convenience, cost, privacy, liquidity, and counterparty risk:

• Centralized exchanges: Usually provide high liquidity and advanced order types. However, users depend on the operator for custody and may face identity verification, withdrawal restrictions, or platform failure.
• Peer-to-peer markets: Connect individual buyers and sellers and may provide escrow or dispute resolution. They offer flexible payment methods but require careful evaluation of fraud and payment-reversal risks.
• Bitcoin ATMs: Allow purchases, and sometimes sales, using cash or cards. They are convenient but often charge high fees and may require identification.
• Direct trades: Two parties transact without a centralized marketplace. This can reduce platform dependence but requires a safe method of coordinating payment, price, physical security, and settlement.

Users should compare the total effective price, including spread and fees, rather than only the displayed market price. They must also consider applicable laws, privacy implications, transaction limits, custody arrangements, and the reversibility of the fiat payment method.

A secure Bitcoin Core installation involves the following steps:

1. Obtain the software: Download Bitcoin Core from the official source.
2. Verify authenticity: Check the release signatures or published hashes using trusted verification information.
3. Install the client: Use the appropriate package for the operating system and restrict unnecessary administrative privileges.
4. Choose storage: Ensure sufficient disk space for the blockchain, or configure pruning if full historical block storage is not required.
5. Configure networking: Permit desired peer connections while avoiding unnecessary exposure of the RPC interface.
6. Start synchronization: Bitcoin Core downloads block headers and blocks and independently validates the blockchain from the genesis block onward.
7. Configure the wallet: If wallet functionality is required, create or load a wallet and make secure backups.
8. Review security: Encrypt sensitive wallet data where supported, protect the host system, and keep the software updated.

The initial synchronization may take significant time, storage, bandwidth, and CPU resources. The node should not be treated as fully synchronized until its chain tip is current.

• Full node: Downloads and independently validates blocks and transactions according to Bitcoin's consensus rules. An archival full node retains historical block data and can serve it to other peers.
• Pruned node: Performs full validation but deletes older block files after they are no longer needed, retaining only a configured amount of recent data and essential chain state. It reduces storage requirements but cannot serve all historical blocks.
• Lightweight client: Does not independently validate every transaction and block. It obtains selected information from servers or peers and therefore makes additional trust or privacy trade-offs.
• Mining node: Constructs candidate blocks and works with mining hardware or a pool to search for valid proof of work. A miner should validate transactions and previous blocks rather than blindly trusting external data.

The key distinction is that full validation concerns verification, whereas archival storage concerns retention. Thus, a properly operating pruned node can still be a validating full node even though it does not retain the entire historical blockchain.

bitcoin-cli is a command-line program that sends JSON-RPC requests to a running Bitcoin Core node. Useful categories include:

• Node information: bitcoin-cli getblockchaininfo reports chain, block height, verification progress, and pruning status.
• Network information: bitcoin-cli getnetworkinfo and bitcoin-cli getpeerinfo show protocol and peer-connection details.
• Blockchain inspection: bitcoin-cli getblockhash HEIGHT obtains a block hash, and bitcoin-cli getblock HASH displays block data.
• Mempool inspection: bitcoin-cli getmempoolinfo summarizes the mempool, while bitcoin-cli getrawmempool lists transaction identifiers.
• Transaction inspection: bitcoin-cli getrawtransaction TXID true returns decoded transaction details when the node has access to the transaction.
• Wallet operations: Depending on the loaded wallet, commands can create addresses, list balances, fund transactions, and sign transactions.

Users should begin on testnet or regtest, consult command help with bitcoin-cli help, and avoid exposing RPC credentials or running unfamiliar wallet-spending commands.

Regression test mode, or regtest, creates a private blockchain under the experimenter's control. A typical experiment is:

1. Start Bitcoin Core with regtest enabled.
2. Create and load a wallet using the wallet-management RPC commands.
3. Generate a new address.
4. Mine blocks to that address using generatetoaddress so that coinbase rewards are created.
5. Mine enough blocks for the coinbase outputs to mature before attempting to spend them.
6. Create a second address and send regtest bitcoin to it.
7. Inspect the mempool to observe the unconfirmed transaction.
8. Generate another block and verify that the transaction receives a confirmation.
9. Decode the transaction and examine its inputs, outputs, fee, and change.

Regtest is safer and faster than experimenting with real bitcoin because it has no market value, requires no public miners, and allows blocks to be generated on demand. It is ideal for testing wallets, RPC programs, scripts, and confirmation-handling logic.

Bitcoin Core exposes a JSON-RPC interface that allows authorized programs to query node state and invoke operations. A client sends a method name and parameters, and the node returns a structured result or error.

Typical uses include:

• Retrieving blockchain, network, mempool, and fee information.
• Loading wallets and generating receiving addresses.
• Creating, funding, signing, and broadcasting transactions.
• Examining blocks and decoded transactions.
• Automating testing and monitoring.

Important security measures are:

• Bind RPC only to trusted interfaces, preferably localhost.
• Use cookie authentication or securely managed RPC credentials.
• Never publish credentials in source code, logs, or public repositories.
• Apply firewall restrictions and encrypted tunnels when remote access is unavoidable.
• Grant applications only the capabilities they require.
• Validate all parameters and display transaction details before authorizing spending.
• Treat RPC access as highly sensitive because wallet-enabled methods may control funds.

The peer-to-peer port and RPC port serve different purposes and should not be confused or exposed using identical security policies.

A safe transaction-building workflow consists of separate stages:

1. Create outputs: The program specifies recipient addresses and amounts.
2. Create a raw transaction: A raw transaction template is produced, optionally with explicitly selected inputs.
3. Fund the transaction: The wallet selects UTXOs, estimates a fee, and usually adds a change output.
4. Review: The program decodes the funded transaction and verifies recipients, amounts, fee, change address, and network.
5. Sign: The wallet signs inputs for which it controls the required keys. In a hardware-wallet or multisignature design, signing may occur externally.
6. Check completeness: The signing response must indicate that all required signatures and scripts are complete.
7. Broadcast: The finalized transaction is submitted to the local node, which validates it before relaying it.
8. Monitor: The application records the transaction identifier and tracks mempool status, confirmations, conflicts, and possible replacement.

Amounts should be handled using exact decimal or integer satoshi representations rather than binary floating-point arithmetic. The application must also avoid duplicate payments when retrying after timeouts.

• Graphical clients: Provide visual controls for balances, payments, settings, and synchronization. They are accessible to users but may hide technical details needed for advanced troubleshooting.
• Command-line clients: Provide precise control and are suitable for administration, scripting, and experimentation. They require knowledge of commands and careful parameter handling.
• Mobile wallets: Emphasize portability, QR scanning, and everyday payments. They may operate as lightweight clients and must protect keys on a frequently connected device.
• Programmatic API clients: Integrate Bitcoin functions into exchanges, merchant systems, payment processors, and monitoring tools. They support automation but require robust authentication, validation, error handling, and key separation.

The appropriate client depends on the purpose. A learner may combine Bitcoin Core with bitcoin-cli on regtest, an everyday user may prefer a mobile or hardware-wallet interface, and a business may use a full node plus an authenticated API. Convenience should be balanced against validation, privacy, custody, and operational security.

A reliable monitoring application should include the following design elements:

• Independent node access: Query a controlled full node rather than relying entirely on a public block explorer.
• Unique payment identifiers: Generate a fresh address or invoice for each order and map it to the expected amount and expiry.
• Mempool detection: Mark a matching transaction as unconfirmed, but do not treat it as irreversible settlement.
• Confirmation policy: Require a configurable number of confirmations based on value, customer risk, and service type.
• Reorganization handling: Recheck the block association and confirmation count because a transaction may lose confirmations during a chain reorganization.
• Conflict and replacement handling: Detect when an unconfirmed transaction is replaced or conflicts with another transaction spending the same inputs.
• Idempotency: Ensure repeated RPC responses or event deliveries cannot create duplicate orders, credits, or refunds.
• Privacy: Avoid address reuse, protect customer mappings, restrict logs, and minimize disclosure to third-party services.
• Security: Separate monitoring from signing systems and give watch-only components no spending keys.

The application should model payment as a changing state, such as unseen, unconfirmed, confirmed, conflicted, or expired, instead of assuming that a transaction is final immediately after broadcast.