Bitcoin Ledger Mechanics From Signing to Block Inclusion

How Bitcoin Ledger Records Every Transaction requires one correction: the hardware signer does not maintain a private database; it creates and stores keys in a secure element, and those keys never leave the chip, while the original cryptocurrency network’s nodes write the permanent public chain. Keep the 24-word recovery phrase offline, verify each receive address and output amount on the device screen, and treat the companion application as a coordinator and viewer, not as a source of truth.

When you prepare a spend, the companion app reads public chain data and builds an unsigned payload from available outputs. The device receives that payload over USB or Bluetooth, shows destination, value, and fee on its trusted display, and signs only after physical approval. The signature returns to the app, which broadcasts the raw entry. Independent nodes check the signature, update the unspent-output set, and include the entry in a block. Your balance and history are reconstructed from those public entries and your account derivation paths, not from a hidden company log.

For accurate self-custody, compare the address shown in the companion app with the address on the hardware screen before sharing it. During a send, inspect each destination and the miner fee on the device display; reject any mismatch or unexpected change output. Test a restore on a spare device or in an isolated environment to confirm the backup works without exposing the seed. A pending spend remains unconfirmed until miners include it in a block; the companion app can display status but cannot force inclusion.

Use the official download page, install firmware only from the companion app, and never type the recovery phrase into a browser, chat, or support form. A caller or message asking for those 24 words is a scam. If the device disconnects, try another cable or port, restart the companion app, and check the official support site for fixes. These habits keep signing keys isolated while the public chain continues to timestamp all valid transfers.

What Each Input and Output Field Means in a Raw Bitcoin Transaction

Decode the byte stream before signing: version, input count, each outpoint, scriptSig, sequence, output count, each satoshi value, locking script, locktime, witness.

Inputs spend earlier outputs. A 32-byte hash identifies the funding transfer; a 4-byte index selects one output inside it. scriptSig carries unlocking data for legacy spends; sequence handles relative timelocks and replacement signaling. SegWit moves signatures into witness fields, so the base input script often stays empty. CompactSize integers prefix counts and variable-length fields.

Outputs pair an 8-byte integer value in satoshis with a locking script. The script defines spending conditions: P2PKH hashes a public key, P2SH hashes a script, P2WPKH uses a witness program, P2TR uses a tweaked key. A hardware signer must display each destination and amount before approval.

Locktime sets the earliest valid block height or timestamp; zero means immediate. Witness data alters weight and wtxid, not txid. Use the official companion app and device screen to confirm each field; unexpected outputs or address mismatches indicate a hostile payload.

How the UTXO Model Tracks Coins Instead of Account Balances

Treat each unspent output as a separate coin that must be spent whole; if a payment needs only part of it, the wallet creates a fresh output for the remainder and signs both sides of the move.

The software never subtracts from a stored number. It gathers the outputs locked to your keys, sums their values, and presents that total as a balance in the companion app. That figure lives in the interface, not on the chain, so two devices holding the same keys can show the same total without any server telling them what it is.

Each spend names earlier outputs as inputs and writes new outputs – one for the recipient, one for change, occasionally one that a miner claims as a fee. Nodes verify that no input was already consumed and that outgoing values do not exceed incoming values; whatever is left becomes the miner’s reward for including the entry. Since inputs are specific and non-overlapping, two conflicting spends of one output cannot both confirm, which removes any need for a running per-user balance. Signing occurs inside the secure element of the hardware wallet, and its screen displays the recipient address and the amount drawn from your own inputs before you approve anything.

Balance is a view, not a field.

Recovery follows identical logic: a seed phrase rebuilds the private keys, and the app rescans blocks for outputs whose locking scripts match your derived addresses. Outputs that fail to appear usually point to a different address-derivation path or a gap limit set too low, rather than coins being gone.

Coin selection changes cost and speed. Fewer, larger outputs keep the entry light; dozens of tiny outputs force more signatures and more weight.

Privacy shifts under this design as well. Change outputs, reused addresses, and combined inputs let observers link spends to one owner. Keep addresses single-use, allow the app to generate fresh change, and confirm the change path on the device screen. When receiving funds, verify the address on the hardware wallet before sharing it – the companion app can show a receive address, yet only the device proves which key governs it. With no account to freeze or edit, a confirmed output stays spendable by whoever holds the matching private key, which makes the seed backup the only genuine path back to your funds.

How a Wallet Signs a Transaction with a Private Key and Publishes It

To sign a payment, build the unsigned instruction in the companion app, then review and approve it on the hardware wallet where the private key stays isolated.

Signing inside the secure element

The hardware wallet generates the private key within its secure element chip and never exports it; during signing, the device receives a hash of the transfer from the companion app, uses the private key to produce a digital signature (for example, ECDSA for many cryptocurrencies), and returns only the signature to the app. The app then attaches the signature to the transfer data and broadcasts the signed transfer to network nodes. Before any signature is created, the device displays the recipient address and amount on its trusted screen; always compare these details with what the companion app shows, because malware on a computer could alter the unsigned instruction before it reaches the device. After broadcasting, the signed transfer enters the mempool, and validators or miners decide whether to include it in a block; a signature proves authorization but does not guarantee confirmation.

How Nodes Check Signatures, Amounts, and Double-Spend Attempts Before Relaying

Run a full node with default mempool checks to reject invalid spends before they reach peers.

For each input, the node evaluates the locking script using the supplied signature and public key. A valid ECDSA or Schnorr proof must match the script’s hash type and clean-stack flags. Amounts are checked by summing inputs and outputs: outputs cannot exceed inputs, no negative values, and no overflow. If an outpoint is missing from the UTXO set or already consumed, the node drops the whole package.

Before relaying to peers, the node scans its mempool for conflicting inputs. If a different unconfirmed spend already uses the same outpoint, the new one is rejected unless it signals replace-by-fee and pays a higher fee. Nodes also enforce standardness rules: script size, push-only, signature encoding, and a locally set minimum relay fee. For a hardware signer, the companion app prepares an unsigned payload; the device signs it; the node then checks the resulting witness or scriptSig against the input. The device screen must display the destination and amount, and you should compare that against the companion app before approving. If the node rejects the spend, the companion app will not broadcast it.

Double-spend attempts across peers get rejected by each node independently. Run your own node, connect to several peers, and review logs for missing-or-spent input errors. For a hardware wallet, always verify the address on the device screen and confirm that the companion app shows the same amount that the node accepted.

How Miners Select Mempool Transactions and Build a Candidate Block

Rank waiting payments by fee density – satoshis per virtual byte – rather than by absolute amount, then fill a block template with the densest entries until the 4,000,000 weight-unit cap binds.

Nodes hold unconfirmed spends in a mempool: an in-memory pool keyed by outpoint, where each entry carries its weight, fee, ancestor set and descendant set. Assembling a template means repeatedly taking the package with the highest fee density, adding parents before children so no input points at an output that has not yet been placed; a child paying well can therefore drag a cheap parent in through child-pays-for-parent accounting. Constraint checks run beside the sort – the weight ceiling, the signature-operation budget, the coinbase and witness commitment reserved at the front of the block, and sequence or locktime conditions that keep an entry ineligible until a stated height or median time passes. Anything beneath the node’s minimum relay threshold is refused outright, and once the pool crosses its memory limit the lowest-density tail is evicted, which means one node can see a payment while its peer does not. Replace-by-fee markers let a sender supersede a stalled spend with a denser version, and the template is rebuilt whenever a fresh tip arrives or a better-paying package appears.

A template is a bid, not a promise: an operator may leave space empty, reorder packages or accept an out-of-band payment, so inclusion depends on the density you offer against the live pool. Verify what you sign before broadcast – a hardware signer with a secure element displays the destination and amount on its own screen and keeps the signing key off the networked machine – because once a payment is confirmed and buried beneath later blocks, undoing it demands redoing the proof-of-work.

Criterion	Check performed by the node	Effect on template order
Fee density	Fee divided by virtual size	Higher density sorts ahead of larger absolute fees
Ancestor score	Combined fee of an entry plus its unconfirmed parents	A cheap parent rides along with an expensive child
Weight	Serialized size adjusted for the witness discount	Sets how many entries fit under 4,000,000 weight units
Signature operations	Count against the per-block script budget	Script-heavy entries are skipped once the budget fills
Spend dependency	Whether each input’s source output exists in the chain or in the same template	Parents are placed before children
Locktime and sequence	Compared against current height or median time	Future-locked entries stay out of the candidate
Relay threshold	Minimum fee density accepted into the pool	Below it, the entry is never offered to a miner
Pool pressure	Memory limit and eviction tail	Low-density entries vanish during congestion
Replacement flag	Signal that a denser version may supersede it	The newer version displaces the older one

How the Merkle Root in a Block Header Commits to Every Included Transaction

Recompute the 32-byte Merkle root from a block’s leaf hashes and compare it with the value in the header; any mismatch proves the data set was altered, truncated, or padded. This check binds the header to the exact set of confirmed spends.

Each leaf is a double-SHA-256 hash of one serialized payment.

Pairs are hashed together, then their outputs are paired again, repeating until one digest remains. If a level holds an odd count, the final digest is duplicated and hashed with itself. The resulting root sits in the 80-byte header, so proof-of-work covers all leaves through one fixed-size commitment.

A light client does not download the full block; it requests a Merkle path, hashes the path with the leaf, and checks the root in the header.

A hardware signer with a secure element cannot rebuild the tree from a tiny screen, so its companion app prepares an unsigned spend, the device shows amount and destination, and the signed bytes are broadcast. The Merkle root still anchors that spend after confirmation: a verifier can produce a branch from the leaf to the header root, so tampering with the block invalidates the header hash and any later blocks built on it.

How Confirmations, Forks, and Reorgs Change Which Ledger History Nodes Accept

Wait for six confirmations before accepting a sizeable incoming payment as settled, and treat a single confirmation as provisional. A full node commits only to the candidate chain carrying the greatest accumulated proof-of-work, so the entries shown by your hardware wallet stay rewritable until that tip hardens. Because the companion app reports whichever tip its node follows, two nodes briefly sitting on different tips will disagree about the same balance – one shows value as spendable, the other shows nothing.

One confirmation equals one block built on top of the block that carried the spend.

Full nodes converge because valid blocks are cheap to check and costly to produce. Acceptance requires a header hash below the target, a parent already present in the node’s index, sufficient work for the current difficulty, and signatures matching the unspent outputs being consumed.

• Header hash at or below the target set by difficulty
• Parent hash known and not already superseded by a heavier branch
• Each input references an unspent output, signed by the key controlling it
• Issuance reward, block weight, and timestamp inside consensus limits
• No output consumed twice within the same branch

Two miners can solve a block at the same height within seconds of each other, splitting the network into two valid branches of identical length. Nodes keep the branch they saw first as active and park the rival in the block index as a side branch. Nothing looks broken to a user: the mempool drains, the spend appears confirmed, and the companion app shows a new balance. Then one side finds the next block, the tie breaks, and all nodes on the losing side silently switch their active tip to the winner – without asking anyone for approval.

Stale blocks, side branches, and tip switching

Side branches linger in the block index instead of vanishing. A node adopts one only when it accumulates more work than the current active chain; blocks left behind on the discarded branch pay their producers nothing on the new tip.

Reorganizations, depth, and the entries your device confirms

A reorganization replaces the top N blocks of the active chain with a heavier set descending from a shared ancestor. Depth matters more than the number of blocks swapped: a one-block shift usually reorders spends, while a deeper shift can erase a payment your device already displayed as received and return those outputs to unspent status. The probability of displacement collapses with each additional block stacked above the one holding your payment, which is exactly why depth-based waiting policies exist. Your own node decides this, not the app, not the explorer you happen to open.

1. Compare your node’s tip hash against a second, independent source
2. Check that the output you were paid still appears as unspent
3. Re-sync the companion app so its history rebuilds from the current tip
4. Do not broadcast a replacement spend until the earlier branch is fully displaced

Your device never rescans the chain on its own. It signs only the inputs the companion app hands over, showing recipient, amount, and fee on its screen for physical approval, while private keys remain sealed inside the secure element. A reorganization cannot touch those keys or the addresses derived from them – what shifts is the chain history attributed to those addresses, because the outputs behind them can be reassigned by a heavier branch. Signing a spend that references an output later moved to a losing branch produces a transfer that propagates and then dies.

Set a waiting threshold per value at risk: one confirmation for small spends, three to six for larger ones, and more for anything irreversible. Verify the tip against a node you control rather than a single explorer.

Q&A:

How does a Bitcoin transaction get from my wallet into the ledger?

A wallet builds a transaction by choosing unspent outputs, called UTXOs, that it can spend. It creates new outputs with amounts and locking scripts, then signs the inputs with the private keys that control those UTXOs. The signed transaction is broadcast to peer nodes. Each node checks the transaction format, signatures, whether the inputs exist and are unspent, and whether the fee is acceptable. If the transaction passes those checks, it enters the node’s mempool. Miners select transactions from their mempools, put them into a candidate block, and repeatedly hash the block header with different nonces. When a miner finds a hash below the target, it broadcasts the block. Other nodes validate the block and every transaction inside it, update their UTXO sets, and append the block to their copy of the chain. The transaction is now recorded in the ledger. Each later block adds one confirmation.

What exactly is being recorded in the Bitcoin ledger: amounts, addresses, or something else?

Bitcoin does not record account balances the way a bank does. It records transaction outputs and the later spending of those outputs. Each transaction has inputs that reference earlier outputs by transaction ID and output index. It also has new outputs, each with a value and a locking script. A wallet balance is the sum of UTXOs that the wallet’s keys can spend. Addresses are usually encoded inside locking scripts, but the ledger itself does not store names or real-world identities. Full nodes keep a UTXO set for fast validation and may also keep block files with the full history. The public record includes amounts, scripts, transaction IDs, block headers, timestamps at the block level, and the order of blocks. Fees are not written as a separate field in most transactions; they are the difference between the sum of inputs and the sum of outputs. A coinbase transaction creates new coins and collects fees for the miner.

Can someone secretly change an old Bitcoin transaction?

Changing an old transaction changes its transaction ID. That breaks the Merkle root in its block, which changes the block header hash, which breaks the link to the next block. To make other nodes accept the edited history, an attacker would need to redo the proof of work for that block and every later block, then outpace the chain built by honest miners. Full nodes reject invalid blocks, so an edit cannot stay hidden. Any change is visible in the chain structure. A powerful attacker with majority hash power could attempt a deep reorganization, but that would be public and costly, and it still would not let them spend coins without the right keys.

What happens when two miners find a valid block at nearly the same time?

This creates a temporary fork. Some nodes see one block first, and other nodes see the other block first. Both blocks extend the same parent, so the network briefly has two competing chain tips. Miners continue mining on whichever tip they saw first. When the next block appears, it builds on one of those tips. Nodes then switch to the branch with the most cumulative proof of work. The block on the losing branch becomes stale, often called an orphan. Transactions from the orphaned block may return to mempools if they are not already in the winning chain. This is normal behavior. Confirmations reduce the risk that a transaction will be affected by such a reorganization. Exchanges and services often wait for several blocks before treating a payment as settled. Reorganizations deeper than one or two blocks are rare.

Why do people say Bitcoin transactions are irreversible, and how many confirmations should I wait for?

Bitcoin transactions are called irreversible because once a transaction is buried under enough proof of work, rewriting it would require redoing a huge amount of work and controlling the chain long enough to replace it. This is not a mathematical impossibility; it is a probabilistic statement. A transaction included in a block has one confirmation. Each later block adds another confirmation. With more confirmations, the chance of a reversal falls sharply under an honest majority of hash power. Common thresholds are one to two confirmations for small payments, three to six for medium payments, and six or more for large payments. The right number depends on the value at risk and the policy of the service receiving the payment. Nodes enforce consensus rules, and miners cannot spend your coins without your keys. A 51% attacker could attempt a double-spend, but they cannot create coins from nothing or spend other people’s UTXOs. They can mainly reverse their own recent transactions.

If Bitcoin has no central bank, how does the ledger know which coins are mine and stop me from spending them twice?

Bitcoin does not track an account balance like a bank. It tracks unspent transaction outputs, often called UTXOs. Each UTXO is an amount of bitcoin locked to a script that usually contains a public key hash or address. When you send coins, your wallet picks one or more UTXOs it can unlock. The new transaction lists those UTXOs as inputs. Each input carries a signature made with your private key. The transaction also creates new outputs: one for the recipient, one for change back to your wallet, and sometimes additional outputs. Nodes check the signature against the script in the referenced UTXO. They also check that the UTXO has not already been spent in the accepted chain or in the mempool. If two transactions try to spend the same UTXO, nodes and miners treat them as a conflict. The first valid one that gets confirmed in a block wins. Once a block is accepted, nodes update their UTXO set by removing spent outputs and adding the new outputs. This is how the ledger knows which coins are available and prevents double spending.

Can I look up my own transaction on the Bitcoin ledger, and what details will I see?

Yes. You can use a block explorer and search for the transaction ID (txid), one of the addresses, or the block height. A confirmed transaction page usually shows the txid, block hash, confirmation count, timestamp, inputs, outputs, amounts in satoshis, scripts, and sometimes witness data. The fee is not a separate field in the raw transaction; it is the difference between the total input value and the total output value. The ledger does not show your name, email, or bank account. Addresses are pseudonymous, so anyone can see movement between addresses but not directly who controls them. If your transaction is still waiting, it may appear as unconfirmed in the mempool. After mining, the transaction becomes part of a block, and its hash is linked into the block’s Merkle tree. Full nodes keep and validate the ledger, while lightweight wallets often rely on servers or filters to find their own transactions.