Hi Sjors, > > >In the case of BIP30, one option could be to have a rule that says: if the > 2014 checkpoint is missing, then enforce the BIP54 Consensus Cleanup > nLockTime rule from genesis. BIP34 can then simply go away. > > > > I'm afraid it's not that simple. If you wanted to fork off from some arbitrary > point prior to the last checkpoint, you'd want to enforce the new consensus > rules from that exact point (not from genesis), but that requires shipping the > full node software with a hash for every possible block that could be forked off > from. It's roughly 8MB of data so it's not impossible, and I even had this > written up as an alternative solution, but I removed it in favor of the solution I > ended up describing. > > The trick is that no blocks obey the BIP54 rule for nLockTime, so they'll all be > rejected and you can fork off starting at block 1.
This ignores the chain splits resulting from the 14 checkpoints that have been removed to get to block 1. If the consensus is to not care about these hard forks causing chain splits, there is really no reason to care about this BIP30 chain split being caused by their removal. 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/035401dbbba6%247ea41790%247bec46b0%24%40voskuil.org.
