2. Wait for the delivery of the product
3. Produce another transaction sending the same 100 BTC to himself
4. Try to convince the network that his transaction to himself was the one that came first.
Once step (1) has taken place, after a few minutes some miner will include the transaction
in a block, say block number 270. After about one hour, five more blocks will have been
added to the chain after that block, with each of those blocks indirectly pointing to the
transaction and thus "confirming" it. At this point, the merchant will accept the payment
as finalized and deliver the product; since we are assuming this is a digital good, delivery
is instant. Now, the attacker creates another transaction sending the 100 BTC to himself. If
the attacker simply releases it into the wild, the transaction will not be processed; miners
will attempt to run APPLY(S,TX) and notice that TX consumes a UTXO which is no
longer in the state. So instead, the attacker creates a "fork" of the blockchain, starting by
mining another version of block 270 pointing to the same block 269 as a parent but with
the new transaction in place of the old one. Because the block data is different, this
requires redoing the proof of work. Furthermore, the attacker's new version of block 270
has a different hash, so the original blocks 271 to 275 do not "point" to it; thus, the original
chain and the attacker's new chain are completely separate. The rule is that in a fork the
longest blockchain is taken to be the truth, and so legitimate miners will work on the 275
chain while the attacker alone is working on the 270 chain. In order for the attacker to
make his blockchain the longest, he would need to have more computational power than
the rest of the network combined in order to catch up (hence, "51% attack").
Merkle Trees