-
Notifications
You must be signed in to change notification settings - Fork 5.4k
BIP Process wishlist
Often it is unclear where the line is drawn between Informational and Standards Track (eg, BIPs 49, 84).
We have several BIPs abandoned by their original author(s) that should probably get reassigned, but also likely nobody wants to be the author for them. Some kind of "ghost author" where someone simply ACKs changes but takes no responsibility for the BIP might be a good idea?
In theory, it's a nice idea, but in practice it seems to rarely be used, and just annoy BIP authors.
TODO: Talk to people apparently annoyed by them.
Historically, we've had a single BIP editor simply passing the torch to the next. It seems time to expand to multiple editors, and some explicit process for adding them should be specified.
The timeout to Rejected status has become controversial. Perhaps split out a new status for BIPs not doing anything but not explicitly rejected?
For more details on this see: https://github.com/bitcoin/bips/pull/1012, https://github.com/bitcoin/bips/pull/1016, https://github.com/bitcoin/bips/pull/1006
A number of BIPs, including the BIP process itself, have found it better to just take the old BIP and revise it, rather than describing changes. It might be useful to have (eg) BIP 174v2 instead of an entirely new BIP number for PSBTv2.
There shouldn't be a significant design change post the BIP moving to a "FINAL" state but minor edits and wording clarifications should be allowed. For significant design changes post moving to the "FINAL" state BIP versions (above) would be handy.
Lightning has created a parallel process called BOLT. My only guess is this is due to a preference for Markdown. If people want to use Markdown, let's restore it as an allowed format.
Figure out what would be needed to merge BOLTs in so there isn't a separate specification repository/process.
I'm open to ideas on this but I think (after Taproot) any soft fork BIP should only state recommended activation parameters by the author(s) and the activation BIP that is recommended by the author(s) (and no changes to the activation BIP should be included within the soft fork BIP itself). Activation BIPs should be finalized prior to including recommended activation parameters in a soft fork BIP. In Taproot's case we are in a scenario where we don't know which activation BIP Core is using and that is not in a situation we want to be in in the future.
What I'm concerned about is a future scenario where a malicious party (e.g Mallory) gets a BIP number, lays out soft fork changes in the BIP, includes complex changes to an activation BIP or maybe even an entirely new activation BIP within the soft fork BIP itself all without community consensus. Mallory then attempts to activate the soft fork either by pressurizing Core maintainers to merge the soft fork changes or releasing an alternative implementation. I wonder to what extent BIP maintainers should step in or be entirely helpless in this scenario. Perhaps a disputed label by BIP maintainers if the soft fork changes (excluding activation) have not been merged into Core. The precedent that Taproot does set (thankfully) is overwhelming consensus within Core and in the wider community on what was included in the Taproot soft fork (excluding activation). What was disputed was what activation BIP should be used, what the activation parameters should be and who should release the activation code. In terms of the actual soft fork (Taproot) it was not disputed barring a single long term contributor's quantum concerns. I expect future soft forks will have the same disagreements on activation mechanisms. But what must continue is a commitment to overwhelming consensus on the soft fork itself. I'm open to ideas on what (if anything) BIP maintainers can do to ensure that is the case.
I am also not sure on this process that BIP authors get to merge whatever they want (potentially downright inaccuracies) into potential soft fork BIPs without review of other subject matter experts. But that would be a bigger change and I'd need to give it more thought.
It is good if we get a second BIP maintainer. To ask Luke to merge in activation parameters that aren't exactly the same activation parameters as the ones in a release he is contributing to is not fair on Luke.
A while back Luke opened a PR (https://github.com/bitcoin/bips/pull/596) to allow BIP editors to merge spelling fixes without notifying and getting an ACK from a BIP champion. I think we either get something like this merged or we ask people not to open PRs with spelling fixes across multiple BIPs. Given there were concerns from etc on Luke's PR it looks likely that it is the latter rather than the former.
Developers may use these lists to estimate which BIPs have become de facto standards, which ones never gained traction or were abandoned.
Versionbits assignments, Lightning extensions, BIP 39 word lists, etc could use some kind of additional number registries and/or document subdirectories.
Default policy changes (e.g. V3), a recommendation but not an obligation for Bitcoin implementations
To address problems such as pinning attacks on Lightning and multiparty protocols (e.g. vaults) there are and will continue to be draft proposals on changing the default policy rules in Bitcoin Core and/or alternative implementations. As these proposals are for default policy rules and **not** consensus rules there is absolutely no obligation for Bitcoin Core and/or alternative implementations to change their default policy rules nor users to run any particular policy rules (default or otherwise). The authors of these draft proposals are clearly recommending what they think the default policy rules should be and what policy rules users should run but it is merely a recommendation. There are a lot of moving parts, subtleties and complexities involved in designing default policy rules so any recommendation(s) to significantly upgrade default policy rules would benefit from being subject to a spec process. This would also aid the review of any policy related pull requests in Bitcoin Core and/or alternative implementations. An interesting recent case study was https://github.com/bitcoin/bitcoin/pull/22665 and Bitcoin Core not implementing the exact wording of BIP 125 RBF. In this case (for various reasons) as a response Bitcoin Core just removed references to BIP 125 and started documenting the replacement to BIP 125 rules in the Bitcoin Core repo instead. However, it is my view that recommendations for default policy rules should be recommendations to all implementations, reviewed by Lightning and multiparty protocol developers (not just Bitcoin Core) and hence they would benefit from being standardized and being subject to a specification process. I will reiterate once again though that policy rules are **not** consensus rules. Consensus rules are much closer to an obligation as divergences from consensus rules risk the user being forked off the blockchain and could ultimately end up in network splits. This does not apply to policy rules.
BIP 340 didn't include a "Layer" in its header, presumably because none of the current options applied. Add a new Layer option (Cryptography) for BIPs such as BIP 340, the draft MuSig BIP and other upcoming cryptography BIPs?
Require at least a one liner saying "This proposal has no backward compatibility issues"? See: https://github.com/bitcoin/bips/pull/1421#issuecomment-1442718400
How a proposed soft fork is deployed and ultimately activated is entirely orthogonal to what is contained in the soft fork. Until the soft fork BIP reaches a point where a deployment is planned the deployment section should be left blank so review can focus on the actual proposal.