Hi Ruben, > >The obvious solution to this problem is to not create the problem in the > >first > place. > > Yes, that is a fair point. Not removing the checkpoints is one way of ensuring > the consensus bug cannot be triggered.
It's more than that. We are contemplating a "consensus bug" that would cause a chain split because the BIP30 exceptions are no longer being covered by any checkpoint. The heights at which this would cause a split are well below all but 3 of the 14 checkpoints. For that to occur 11 formerly checkpointed blocks would first have to be popped, given the existence of a stronger chain capable of triggering the above bug. This implies 11 more chain splits, depending at which point nodes adopted the checkpoint soft fork(s), just to reach this bug, and up to 14 possible in total. It makes no sense to fix this bug without first fixing chain splits that would be triggered *over 200,000 blocks less deep* than this BIP30 bug. And the only way to fix those is to not remove the checkpoints - which renders this bug inert. > I'm agnostic about whether having > checkpoints is also a reason to forgo consensus checks such as BIP30 (or my > proposed alternative of checking the coinbase TXID for uniqueness and > ensuring no future collision). There is certainly a reason, the checkpoints are consensus rules. > Even though checkpoints essentially force your node to halt if something were > invalid up until that point, Right, if any other rule conflicted with them then the chain would stall forever at that point. That is not the applied meaning of these rules. The checkpoints declare that the blocks are required and therefore inherently valid. The reason we are having this conversation is the contemplated removal of the checkpoints, which also implies that other validation within covered blocks is not consensus. > I still think there is value in being able to verify that the rules were > followed. Like them or not, checkpoints are the rules that are required to be followed. > >Solution C could be to remove it, but restore the previous UTXO > > Yes, as Sjors also pointed out, I do think it is best to be precise about > which of > the duplicates you're keeping. In fact, it's probably required to ensure the > rolling UTXO set hash remains consistent. Sure, but these are implementation details, not a matter of consensus. The consensus behavior would be that the second output is popped with its block and the first remains with its block. Assuming it would be written up, that's how I would recommend handling it. Best, Eric -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/035301dbbba6%24701dd490%2450597db0%24%40voskuil.org.
