For user32260: Bill sells Sally some apples for £2.50
Bill is a fruit vendor. Sally wants to buy some apples for £2.50. Sally wishes to use Bitcoin to pay Bill for the apples. Bill presents Sally his payment address, for example as a quickresponse code:
Sally uses a Bitcoin wallet on her smartphone to scan the code. She is presented a screen where she can enter an amount to send to Bill's address. She types '£2.50' and presses send. A moment later Bill's tablet notifies him that there is an incoming payment pending, which is not confirmed yet. About ten* minutes later, the payment is finalized** when it gets confirmed***.
Under the hood
1) The payment order (Transaction):
The software on Sally's smartphone checks whether Sally has a sufficient balance and then creates a payment order, which we'll call Transaction. This transaction is composed of three pieces of information: Which "coins" to spend, the recipient, and a signature.
Sally's wallet is connected to other participants in the network. The wallet passes the transaction to all of them, who in turn pass it on to all of their connections. Within a few seconds, every participant in the network has received notification of Sally's payment order. Each and every participant checks whether the listed "coins" exist, and whether the signatory is the owner.
So far, Sally's payment is only a promise, because it is still unconfirmed.
To change that, some network participants, which we'll call miners, work on confirming these transactions. The miners grab all the unconfirmed transactions and try to pack them into a set. When this set doesn't fulfill the difficulty requirement, they reshuffle it and try again. At some point, somebody finds a set with the right properties: A valid block.
Just as with the transactions before, they send this block to all their connections, who in turn forward it to theirs. Everyone checks the work (to confirm that the block follows the rules) and when satisfied, applies the included transactions to their own ledger: The transactions get executed and the "coins" that were used by the senders get invalidated, whereas the recipients gain new "coins" as ordered by the transactions. Sally's transaction (and all the others) is now confirmed. Bill can now spend the "coins" he received from Sally.
3) The Blockchain
Let's take a step back. Before Sally paid Bill, Sally got the bitcoins from Alice. Obviously, the order here is crucial. She can't pay Bill if she didn't get the money from Alice first.
Generally, transactions can only spend "coins" that have already been created. This is why each block has a fixed position: Each block references his direct predecessor. E.g.
Block 90 says that
Block 89 preceded him, in turn
Block 89 names
Block 88 as his predecessor, and so forth, until
Block 2 points at the first block, the
Genesis Block ← 2 ← … ← 88 ← 89 ← 90
The eponymic blockchain has useful properties:
- Deterministic results: Everyone can start from the
Genesis Block and apply each block consecutively to arrive at the same result.
- Synchronization & Consensus: When you have applied the latest block, the balances in your ledger have the exact same state as in all the other participants' ledgers.
- Unchangeable History: As each block builds upon its predecessor, each new block buries the history under more work (see graphic below):
Illustration: Mark Montgomery/IEEE Spectrum
*What keeps the average block time at 10 minutes?
**Why is 6 the number of confirms that is considered secure?
***What are bitcoin "confirmations"?
"Coins" is a simplification for Unspent transaction Outputs