Today we wrap up chapter 5 from Bitcoin: A Work in Progress.
One question to ask is whether it’s really useful to check historical blocks after loading the snapshot. Of course, if you’re restoring an old wallet from a backup, you’ll need to scan historical blocks for your transaction history, but let’s disregard that scenario for now.
Assuming you’re a new user, the first thing you want to do is receive coins. You want to be sure these coins will later be accepted by others. And you may want to make sure there’s really a 21 million BTC limit. Do you need to check historical blocks to know this?
To start with the second question — checking the 21 million limit — the answer is no. You can calculate the total amount of Bitcoin in existence right now by adding up all the values in the UTXO set. And then you can look at the source to understand how many coins can be created in the future. There’s no need to see past blocks for that.
However, to know if others will accept the coins you received, you need to know that the person who sent you the coins didn’t create them out of thin air or steal them. This goes back to the question of if a malicious developer can get away with this. Let’s look into how this compares to manipulating Assume Valid.
Let’s say developers create some coins out of thin air and add them to the UTXO set, or that they reassign existing coins to themselves. Anyone verifying the snapshot would find out, so again, code transparency mitigates some of this.
But where, in the Assume Valid example above, the developers would have to create an invalid block right away, before making a new software release, that’s not necessary here. The new or stolen coins would exist in your UTXO set without ever having been in a block. So miners and existing node operators won’t initially detect this, because there’s no invalid block floating around.
But there’s a catch: When you, as the new user, receive a coin that was created out of nowhere, it never gets confirmed in a block. The new transaction won’t be mined, because miners have the correct UTXO set and recognize the transaction as invalid.
What if miners are in on it? Then the transaction would confirm and you’d have been fooled. However, every other node would reject the new block, and the attack would now be visible to everyone involved.
Developers could be very patient though. Instead of immediately trying to spend the from-thin-air coins, they could wait many years. Perhaps by that time, many miners will have reinstalled their node, along with the manipulated snapshot, and synced it. Perhaps many exchanges did so as well. And many regular users. So when they finally spend the from-thin-air coins, perhaps the block is only considered invalid by a small group of old school hardcore bitcoiners.
So as before, this attack requires much of the world to conspire against you, but as far as global conspiracies go, it may be ever so slightly less difficult to get away with.
One way to mitigate this attack is for every block to include a hash of the current UTXO snapshot. This would be a soft fork. That way, every node verifies the snapshot, and it wouldn’t have to be included in the software.
However, as things stand today, producing such a hash would increase the verification time for a block from a few seconds to more than a minute. So a different type of hash has been proposed: MuHash.
There will probably be a lot more discussion before such a soft fork is even proposed. At the time of writing - both the book and this newsletter, AssumeUTXO is still being developed. Nodes can already produce snapshots of their UTXO set, but the code to actually load and use a snapshot is still undergoing review.