The wallet first builds a payment proposal
When you enter a recipient's address and an amount, the wallet does not select a file containing coins. It finds previous outputs that your keys can spend and uses them as the inputs of a new transaction. It then creates an output for the recipient, usually a change output back to you, and selects a fee.
Before it is signed correctly, the proposal by itself gives the network no authority to spend anything. The wallet must check the amounts and conditions, prepare the exact data to be signed and only then send the result to a connected node. A well-designed signing wallet shows the user the destination, amount and fee before approval.
Inputs point backwards; outputs point forwards
Every ordinary input identifies a particular output of an older transaction by an identifier and an index. It also supplies the data required to satisfy that output's spending condition. New outputs specify an amount in satoshis and a new condition that a future spender will have to satisfy.
A transaction therefore does not issue an instruction such as ‘subtract from John's account and add to Peter's’. It consumes the selected outputs in full and creates new ones. If the inputs are worth more than the payment and fee, the difference is normally returned to the sender in a separate output. Article 45 examines this model in detail.
- an input points to a particular older unspent output
- an output specifies an amount and a condition for future spending
- the difference between inputs and outputs may be claimed by a miner as the fee
The signature travels; the private key stays at home
The wallet uses the private key to sign specified parts of the transaction. The signature lets nodes verify that the required authority approved the payment and that the protected data has not changed since signing. The private key itself is not sent to either the recipient or the network.
The signed transaction is sent to one or more nodes. They check it independently and may relay a valid transaction to other peers. Propagation is not confirmation, however: at this stage it is an unconfirmed transaction that may not yet appear in any block.
The recipient watches a record, not an arriving object
The recipient's wallet notices that a new output matches a condition its key can later satisfy. It may display it immediately as a pending payment. Inclusion in a valid block creates the first confirmation, while later blocks reduce the probability that the ordering of history will change.
This explanation does not make Bitcoin an ordinary bank account. The difference is that validity does not have to be certified by one operator of an account database. From public data and rules, each full node can determine for itself whether the inputs exist, remain unspent and do not create unauthorized value.