Today we continue chapter 6 from Bitcoin: A Work in Progress.
here are two ways you can learn about a transaction. Someone can send it to you via the network, in which case you add it to your mempool. Or, it can be part of a block you receive.
How would you validate the transaction in the first scenario? With Utreexo, you have the top of the trees in your RAM. The sender is responsible for sending the transaction, as well as the proof that the transaction is valid, which also includes information for you so you know where to find it in the forest. If the sender doesn’t support Utreexo and doesn’t provide the proof, your node could simply ignore the transaction.
But what about the second scenario? If a miner mines a block and a transaction is in there, the block doesn’t contain the proof. To get this proof, you need the help of a bridge node. This is a node that has the actual UTXO set, the old-fashioned way, so it has lots of RAM or it’s just slow. And it produces all these proofs and it sends them around to whoever wants them.
When a bridge node receives a transaction that doesn’t have a Merkle proof, it takes the proof it has, attaches it to the transaction, and sends it to other Utreexo nodes. The same goes for entire blocks. You don’t have to be directly connected to such a bridge node, as other Utreexo-aware nodes can relay blocks with the proofs attached. From the perspective of the Utreexo node, the bridge node is just a Utreexo node, and from the perspective of the old-fashioned nodes, it’s just an old-fashioned node.
There’s nothing magical about bridge nodes. Any node that has the original UTXO set can construct the proof for any transaction. But doing so would defeat the purpose of Utreexo, because keeping track of both the regular UTXO set and these proofs takes a lot of memory.
So these bridge nodes do the translation between the current world of nodes that track the UTXO set in memory and these new Utreexo-enabled nodes that don’t have to. As long as one bridge node exists, it can bootstrap the network. However, this relies on these bridge nodes being backed by people with good intentions. But these nodes could change, or disappear, or run out of battery.
Looking at the longterm picture, if people like Utreexo given the advantages — or even if they don’t like it — if the UTXO set gets too big and takes too long to sync on any normal computer, then you could basically make a soft fork that requires all proofs to be in the block.^[You’d include the hash of the proofs somewhere in the coinbase transaction. As we explained in chapter @sec:segwit for SegWit, the proofs themselves would go in a special place inside the block that old nodes don’t see.] By including proofs in the blocks, they’re guaranteed to be available to all nodes.
The tradeoff there is that bigger blocks require more bandwidth and storage, but less RAM is used. At the moment, bandwidth is probably a bigger constraint than RAM, so a soft fork isn’t likely to happen, but this could change in the decades ahead.