What actually happens when you send bitcoin?

You pressed Send. What changed?

Your wallet shows a pending payment. The recipient has not received a digital coin moving through a pipe. Your software has prepared a transaction that proposes spending existing outputs and creating new ones.

Let’s follow one fictional input worth 100,000 sats. The wallet creates a recipient output of 70,000 sats and a change output of 29,000 sats. The remaining 1,000 sats is the fee.

100,000 input = 70,000 recipient + 29,000 change + 1,000 fee

A satoshi is one hundred-millionth of a bitcoin. These teaching amounts are deliberately simple. The fixed fee does not represent a live network estimate or a suggested fee.

Five moments that are easy to blur together

First, the wallet constructs the proposed spend. Second, it satisfies the spending conditions, often by producing signatures. Third, it sends the transaction to a peer, which checks it and may keep and relay it. Fourth, a miner includes it in a block that a node accepts into its active chain. Fifth, later blocks build on that block.

Only the fourth moment gives the payment its first confirmation. Before that, “pending” describes an observation about an unconfirmed transaction. It is not a reservation guaranteeing a place in the next block.

A peer’s mempool is local. One peer may have accepted a transaction another has not seen or will not relay. There is no single global waiting room where every node agrees on exactly what comes next.

Predict the effect of a larger payment

Keep the input and fee fixed. If the recipient amount rises to 80,000 sats, what must change? The wallet cannot spend the same 100,000 sats twice. It has only 99,000 sats to divide into outputs after the fee. Try that prediction in the experiment.

The arithmetic is necessary, but not sufficient

At 80,000 sats to the recipient, change becomes 19,000. At 99,000, our arithmetic model has zero change. At 99,001, the proposed spend exceeds its budget and cannot be constructed in this model.

Real wallets have more work to do. They select outputs, estimate transaction weight and fees, avoid inappropriate tiny outputs, satisfy scripts, and handle network policy. A zero-change arithmetic result is not a claim that a wallet should serialize a zero-valued change output. The example does not attempt complete validation.

The fee is the difference between total input and output values. It is not a third ordinary output with a miner’s address. A miner can claim fees in the block’s coinbase transaction, subject to Bitcoin’s rules.

A confirmation describes a chain position

When a transaction appears in a block on a node’s active chain, its confirmation count is one. If one more accepted block follows, it becomes two. The count depends on the observer’s current chain and can change during a reorganization.

More confirmations change the evidence behind settlement decisions; they do not convert a probabilistic system into an unconditional guarantee. This experiment offers manual steps so that you can inspect the sequence. It is not a clock, an estimate of confirmation time, or a promise that a valid transaction will be mined.

Inspect the smallest useful model

The central calculation can be written as a pure function, with no wallet or network access:

function changeFor(recipient: number): number {
  const input = 100_000;
  const fee = 1_000;
  if (!Number.isSafeInteger(recipient) || recipient < 0) {
    throw new Error('Use whole non-negative sats');
  }
  const change = input - recipient - fee;
  if (change < 0) throw new Error('Insufficient input value');
  return change;
}

Expected results: changeFor(70_000) returns 29_000; changeFor(80_000) returns 19_000; changeFor(99_001) throws. The interface also rejects blank, decimal and negative text instead of silently rounding it.

Advance the experiment to Relay, then change the amount. Expected result: the visual returns to Construct. A later staged state cannot remain attached to a different transaction proposal. Reset restores the initial 70,000 sat recipient amount.

The inspectable object is a teaching record, not Bitcoin serialization. You cannot broadcast it. No private key, real signature, mining work, live mempool query, or network payment is involved.