Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement BIPXXX's new softfork rules (The Great Consensus Cleanup) #15482
Based on #15481. BIP available at https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki (I'll post it on the mailing list later tonight, hopefully).
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Given the issues with the mailing list, and the lack of a PR adding the BIP, I'm going to write some thoughts I have regarding the general idea of the proposal here. My apologies if this seems like the wrong forum.
I'm a bit surprised that the possibility of using forward blocks to achieve future scaling is not mentioned in the BIP or PR, since the absolute removal of the time-warp attack vector closes off the possibility of using the bug for forward- and backwards-compatible soft-fork scaling in the future, as I covered in my talk at Scaling Bitcoin last year.
While developing the idea of forward blocks I sent a vulnerability report email to some of the senior Bitcoin Core developers. In it I outlayed some analysis of the attack vectors, and a suggested solution which both prevents the sort of attacks which could be devastating to the network, while still allowing uses of the time-warp "feature" to achieve on-chain scaling when it becomes necessary at some point in the future. I'll quote that part of the email here:
This approach additionally has the advantage of being less disruptive than what is implemented in this PR. No rule changes are engaged at all until such time as the adjustment block's timestamp is 4 hours ahead of median time past, so there is no risk to un-upgraded miners outside of a time-warp regime because a block more than 2 hours in the future is considered invalid. I think this modified rule would make it safe to switch to BIP8 instead of BIP9 for deployment.
@maaku e.a. FYI mailinglist threads:
Can you split the soft-fork rules into separate commits, away from the activation logic? E.g. it's hard to spot the
Shameless review plug for #12134, so we can test the interaction with older nodes.