Skip to content
Financial Context Wiki

Bitcoin

Bitcoin is a peer-to-peer protocol and network whose native units are controlled through UTXO spending conditions, proof-of-work ordering and independent full-node validation.

Updated

For education only. Bitcoin confirmation is probabilistic, transactions and keys can be lost or stolen, and protocol validity does not guarantee price, liquidity, privacy or custodial solvency.

Direct answer

Bitcoin is an open-source peer-to-peer protocol, network and ledger system. BTC is its native unit and 1 BTC = 100,000,000 satoshis. Rather than storing account balances, the ledger records unspent transaction outputs (UTXOs) with spending conditions. A wallet manages keys or descriptors, finds controlled outputs, constructs transactions and produces the required signatures or scripts; the wallet does not contain the coins themselves.

Miners select transactions and propose proof-of-work blocks. Full nodes independently validate transaction scripts, unspent inputs, value conservation, block weight, proof of work and coinbase limits. A miner cannot force a validating node to accept invalid signatures or excess subsidy, although concentrated hash power can censor transactions or attempt to reorganize valid recent history.

The active chain is a node’s valid chain with the greatest accumulated work. Inclusion depth reduces reorganization risk but does not create deterministic finality. Bitcoin’s protocol validity, issuance schedule and custody control are distinct from market price, legal treatment, exchange solvency and “digital gold” narratives.

1
Create

A wallet constructs a transaction with destination, value, fee parameters, and replay-protection data such as spent inputs or a nonce.

How it works

  1. Pin the network, software and ruleset, node or wallet trust model, custody model and recipient’s amount-specific confirmation policy.
  2. Verify the destination network, address or locking script and amount; select mature spendable UTXOs controlled by the intended keys or script path.
  3. Construct inputs, recipient output, optional change output and fee in integer satoshis. Check fee = sum(inputs) - sum(outputs) and estimate weight, virtual size and sat/vB rate.
  4. In the signing environment, inspect every output, amount, fee, sequence, locktime and replaceability policy before satisfying the spending conditions.
  5. Broadcast through chosen peers or RPC. Separate local validation, mempool admission, relay and replacement policy from consensus validity and eventual mining.
  6. Miners build candidate blocks; full nodes accept only valid proof-of-work blocks and follow the valid chain with most accumulated work. Track inclusion height, confirmations, conflicts and reorganization.
  7. Apply the recipient’s risk threshold, then reconcile resulting UTXOs, change and fees; secure backups and custody evidence, monitor privacy leakage and keep wallet and node rules current.

Each node’s mempool is local and policy-driven, not a global consensus queue. A valid transaction can fail to relay or remain unmined. Fees depend mainly on transaction weight, fee rate and block-space demand, not the amount transferred. Change is an ordinary output, not a protocol field or an extra charge.

Issuance occurs through a block’s coinbase transaction. Under current rules, the subsidy halves every 210,000 blocks; after height 840,000 it is 3.125 BTC per block, plus transaction fees. Coinbase outputs require 100 blocks of maturity before spending. The common 21-million limit is an asymptotic maximum under the current schedule, not current circulating supply or a price guarantee.

Example

  • UTXO accounting. One input is 0.30500000 BTC = 30,500,000 sat. The wallet creates a 20,000,000 sat payment and 10,480,000 sat change. Fee is 30,500,000 - 20,000,000 - 10,480,000 = 20,000 sat = 0.00020000 BTC. At 250 vB, the fee rate is 20,000 / 250 = 80 sat/vB; change is not another fee.
  • Fee-rate sensitivity. The same illustrative 141 vB transaction costs 141 x 12 = 1,692 sat at 12 sat/vB and 141 x 40 = 5,640 sat at 40 sat/vB. Sending 0.01 BTC instead of 1 BTC does not by itself change that size, although coin selection, script and output count can.
  • Confirmation depth. A transaction included at height 900,000 has 1 confirmation when the tip is 900,000 and 900,005 - 900,000 + 1 = 6 confirmations at tip 900,005. If a new best-work chain retains it with tip 900,003, depth is 4; if the replacement chain omits it, it returns to unconfirmed or conflicted state.
  • Coinbase value. After four halvings, subsidy is 50 / 2^4 = 3.125 BTC. If included fees total 0.42 BTC, permitted coinbase output value is 3.125 + 0.42 = 3.545 BTC. Only the subsidy is new issuance; the fee component transfers existing satoshis, and the output still observes coinbase maturity.

Risks

  • Wrong network, address, script or amount.
  • Seed, private key or recovery data is lost.
  • Keys are stolen through phishing or social engineering.
  • Wallet, signer, firmware or supply chain is malicious.
  • Clipboard or display substitutes the destination.
  • Change output or coin selection is wrong.
  • Virtual size, fee-rate or satoshi units are miscalculated.
  • Dust or nonstandard policy blocks relay.
  • Local mempool rejects, evicts or fails to propagate a transaction.
  • Unconfirmed conflict or replacement invalidates acceptance.
  • A recent-block reorganization reduces confirmation depth.
  • Hash-power concentration enables censorship or reorganization attempts.
  • Mining-pool concentration or network partition delays inclusion.
  • Software bug or consensus split produces incompatible views.
  • Address reuse and change heuristics link public activity.
  • IP metadata, eclipse or an untrusted server misleads the wallet.
  • Custodian insolvency, freeze or withdrawal halt blocks access.
  • Price, liquidity, leverage or FX volatility causes loss.
  • Legal, tax or reporting treatment changes.
  • Backup, inheritance, coercion or disaster recovery fails.

Common misconceptions

  • A wallet or address contains a BTC account balance. Wallet software derives a view from spendable UTXOs; an exchange balance is instead a claim on the custodian.
  • Mempool acceptance means consensus confirmation. Mempools use local policy, and block inclusion is a separate event.
  • Six confirmations provide absolute finality. Depth reduces probabilistic reorganization risk; required depth is recipient and context specific.
  • Miners can create or spend arbitrary valid BTC. Full nodes enforce scripts, unspent inputs and subsidy limits, though miners can censor, order and attempt reorganizations.
  • Bitcoin is anonymous or self-custody is automatically safe. The ledger is public and pseudonymous, while key management, backups and transaction verification remain user responsibilities.

Sources

Navigation

Search the wiki...