Re: [bitcoindev] The Tragic Tale of BIP30

[Eric Voskuil <eric@voskuil.org>]

Hi Sjors,

The point I’m making is that introducing more complexity to try and mitigate this issue, while ignoring far more likely issues resulting from these various hard forks, seems irrational and inconsistent. So either way I would close out this question.

It would make more sense to me to have the project(s) that have deployed such hard forks finally BIP all of them, as some have been deployed silently. This would allow all implementations to know what the consensus might actually be (or not) without having to fish through source code repos.

At least one of these supposedly inert hard forks (silently deployed) has resulted in a very likely future chain split, which the Consensus Cleanup effort is attempting to mitigate. Interestingly enough it pertains directly to bip30.

At least this way various projects and their consumers can make informed decisions about how they perceive the risk and the benefit. Some might simply take BC at its word (that removing checkpoints is unlikely to cause a chain split) and simply ignore it.

e

> On May 10, 2025, at 12:24, Sjors Provoost <sjors@sprovoost.nl> wrote:
> 
> Hi Eric,
> 
> I agree that deep-reorg BIP30 handling is not important. Although it _is_ an interesting exercise which helps to better understand consensus code. I think people got distracted a bit by recent drama.
> 
> The Bitcoin Core project "decided" many years ago to not prioritise the graceful handling of extremely deep reorgs. You already stated your disagreement with that approach back then. The dropping of checkpoints is a continuation of that.
> 
> The only thing that would motivate me to bring back checkpoints (i.e. undo the PR that dropped them) is an attack that doesn't involve alien technology.
> 
> At the same time I don't object to, and might even review, changes that:
> 
> 1. are simple enough, like Solution C earlier in the thread; or
> 2. someone writes a thorough BIP that goes though all the ways different (versions of) implementations handle extreme reorgs, and comes up with simple mitigations that make the handling consistent
> 
> As long as they don't bring checkpoints back. I think they've outlived their usefulness as consensus training wheels and now they're just an invitation for legal attacks (or future developer laziness).
> 
> - Sjors
> 
>> Op 10 mei 2025, om 17:39 heeft Eric Voskuil <eric@voskuil.org> het volgende geschreven:
>> 
>> This thread seems to have gone silent. Are these pending hard forks no longer interesting?
>> 
>> e
>> 
>>> 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 bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4AC2B1A6-23F3-4A06-808F-448D9DD58FE2%40sprovoost.nl.

-- 
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/197BF722-4D8F-4796-8FBC-1F002D2CCE31%40voskuil.org.