AssumeUTXO Mainnet Readiness Tracking about bitcoin

[Sjors]

I think "Make params configurable/not hardcoded params" should be under "critical conceptual discussion". Not the part about flexibility, which I agree is low priority.

What's more fundamental is the question of whether these parameters should be "blessed" by the Bitcoin Core project.

One could argue that there is no "blessing", because these snapshots can be objectively assessed. A snapshot hash is valid if and only if background validation yields the same result. Any other snapshot, if it somehow makes into the code, is either a bug or an exploit.

This makes this feature different from checkpoints in a fundamental way. A checkpoint can be abused to override the most-work valid chain. Once enough people honor it, it becomes a fait accompli because miners are incentivised to work on it - eventually making it the most-work chain. (after which it can be deleted, and people can pretend it never happened)

The same can't be achieved with an invalid snapshot. Such forgery can always be demonstrated as long as a single person has an archive of the blockchain all the way back to genesis.

Still, in a far future where perhaps few users actually perform the background validation, a technically sound argument may not matter in the political reality.

A thought experiment to clarify this. The US Treasury finally issues their one trillion dollar coin. They do so by creating their own UTXO snapshot and forcing maintainers to include it. To avoid a chain split existing nodes on the network, they don't actually move the coin, but borrow against it. A few generations go by, more and more nodes will have be reinstalled and synced based on this new snapshot.

In this particular scenario I don't think it matters at all if the hash is part of chainparams or if it's flexible. But there may be a less extreme scenario's where it does. Which is why I think some discussion is warranted.

Meanwhile there is a major downside to not hardcoding the parameters, in that it makes the feature much harder to use. A user would have to find some place to download it, verify a hash and a PGP signature. It's less obvious how we could add p2p snapshot functionality later, because we have no hash to ask for and check against.

So on balance, because of the difference with checkpoints I explained above, my current thinking is that it's alright to include these params.

How frequently should we update testnet/signet params

Imo those params are only there to test the functionality. They don't need to be fresh. If the are nuked, we can add new params a year after the new genesis block (it's hard to test this feature if the snapshot is too close to the start of the chain).

[maflcko]

Not sure about your "optional" issues. The nTx violations currently may lead to a crash of the node (#29261 (comment)). A crash doesn't seem "optional" to fix, no?

[Sjors]

That PR also gives us a clean way to drop the BLOCK_ASSUMED_VALID flag, because it was never used on a mainnet node.

[fjahr]

Moved #29370 to the critical category

[fjahr]

Thanks @Sjors , I added some thoughts inline, then deleted most of it again because it was way too convoluted :) I think the tldr for me is: You ask if including the params in the code open up any new attack vectors. And in my mind the answer is no, because if an attacker can influence the code that users are actually running, then they have unlimited options to profit from that. For the alternative, configurable params, I am not so sure that it doesn't introduce new attack vectors and I think this hasn't been thought through enough because there was consensus to add the code with chainparams.

I think "Make params configurable/not hardcoded params" should be under "critical conceptual discussion". Not the part about flexibility, which I agree is low priority.

My thinking is that we can have that discussion afterwards when the feature sees some adoption and there is interest in not relying on the params. In my mind it would only be critical if hardcoding for now would prevent us from moving away from it in the future. But this isn't consensus, so there is no issue with doing this :) I am happy to have such discussion now but I don't think we need a resolution before anyone can use au on mainnet. If there is consensus for moving away from hardcoded params before we are done with the "critical" section here, then there will be PR that is added to the critical list that implements that functionality and the mainnet params PR will be removed from the list. If we merge the params first and then agree on not hardcoding them anymore, the params will simply be removed with that PR later.

Can you say what you mean with "the part about flexibility" that is different from configurable params? I am not sure we are thinking of the same thing there.

What's more fundamental is the question of whether these parameters should be "blessed" by the Bitcoin Core project.

One could argue that there is no "blessing", because these snapshots can be objectively assessed. A snapshot hash is valid if and only if background validation yields the same result. Any other snapshot, if it somehow makes into the code, is either a bug or an exploit.

I would call it a "temporary blessing" if anything because it's really all about the time window before the background sync finishes. If users could wait for the background validation to complete, they would just be doing IBD.
It should be kept in mind that this was always the fundamental assumption (pun intended) of the project: the parameters in the code are a blessing just like the code itself is a blessing. If you trust the developers with a bitcoin core release and the code in it you can also trust them with the included chain params.

This makes this feature different from checkpoints in a fundamental way. A checkpoint can be abused to override the most-work valid chain. Once enough people honor it, it becomes a fait accompli because miners are incentivised to work on it - eventually making it the most-work chain. (after which it can be deleted, and people can pretend it never happened)

The same can't be achieved with an invalid snapshot. Such forgery can always be demonstrated as long as a single person has an archive of the blockchain all the way back to genesis.

Still, in a far future where perhaps few users actually perform the background validation, a technically sound argument may not matter in the political reality.

A thought experiment to clarify this. The US Treasury finally issues their one trillion dollar coin. They do so by creating their own UTXO snapshot and forcing maintainers to include it. To avoid a chain split existing nodes on the network, they don't actually move the coin, but borrow against it. A few generations go by, more and more nodes will have be reinstalled and synced based on this new snapshot.

If the government can force core developers to include any code they like, assumeutxo params or something else, the project is kind of lonst and people should resort to running forks instead. Creating coins out of thin air should still be easily detectable if some check the snapshot against their own node at a specific height, even if nobody has the full chain anymore. So I don't think assumeutxo itself adds a new attack vector here.

In this particular scenario I don't think it matters at all if the hash is part of chainparams or if it's flexible. But there may be a less extreme scenario's where it does. Which is why I think some discussion is warranted.

Meanwhile there is a major downside to not hardcoding the parameters, in that it makes the feature much harder to use. A user would have to find some place to download it, verify a hash and a PGP signature. It's less obvious how we could add p2p snapshot functionality later, because we have no hash to ask for and check against.

So on balance, because of the difference with checkpoints I explained above, my current thinking is that it's alright to include these params.

How frequently should we update testnet/signet params

Imo those params are only there to test the functionality. They don't need to be fresh. If the are nuked, we can add new params a year after the new genesis block (it's hard to test this feature if the snapshot is too close to the start of the chain).

Ok, that would work for me.

[luke-jr]

#28598 should be in critical

[fjahr]

#28598 should be in critical

I considered this but so far it seems to me that all other reviewers of #28616 didn't see it as critical (myself included) or even doubted a fix was needed at all. Examples: #28616 (comment) and #28616 (comment). If there are more reviews/comments added that are in support of making it critical, or if I have missed comments in that direction from other contributors, please let me know and I will move it.