Ordering and the virtual chain
Colouring blocks is a means, not an end. What a ledger needs is a single sequence that every node computes independently and agrees on.
The recipe: follow the selected parent chain from the genesis block, and at each step write down the blocks that chain block merged before writing down the chain block itself. Within a merge set, blue blocks go first — but only as far as the DAG allows, because a parent must never be ordered after its child.
The dashed V node is the virtual block: a hypothetical block whose parents are the current tips. Its selected parent chain defines the order of everything. That is how a real node does it too.
Click a block to edit the transaction it carries. Format: Alice -> Bob: 20
A double spend, resolved by ordering
Alice starts with 100 KAS. Block A spends 80 of it to Bob; block B spends
the same 80 to Carol. Two conflicting payments, broadcast at the same instant,
neither miner aware of the other. Nothing in the DAG marks either as fraudulent
— both are perfectly valid blocks.
The order decides. Whichever comes first is paid; the second is rejected for
insufficient funds when its turn arrives. Right now A’s branch is heavier, so
Bob is paid and Carol is not. Notice the knock-on: Carol’s onward payment to
Erin fails too, because she never received the coin.
Reorgs, and what confirmations measure
Switch to the BlockDAG demo, select tip H, and add
two blocks onto Carol’s branch. The first only ties the two branches — the
tie-break holds. The second outweighs A’s branch, the selected parent chain
swings across, and the ledger flips to pay Carol.
Block A is not deleted. It is still in the order, just later, where its coin
is already spent. That is precisely what confirmations measure: not whether a
transaction exists, but how much work an attacker would have to out-mine to move
it behind a conflicting one.