BIP 54: progress to Complete #2172

I have concluded all planned work on BIP 54. I believe it represents a net improvement and is ready for adoption by the Bitcoin community. As per BIP 3, this updates its status to Complete.

I had another look at test vectors and reference implementation. Concerns and issues have been discussed on the mailing list and are documented in the proposal. LGTM.

ACK

process wise this seems like a fast merge

This PR was just a Metadata update and a link update for the reference implementation. Updating a BIP to Complete is a determination made by the Authors to signal that they have finished their planned work.

Relevant section of BIP3:

When the authors have concluded all planned work on their proposal, are confident that their BIP represents a net improvement, is clear, comprehensive, and is ready for adoption by the Bitcoin community, they may update the BIP’s status to Complete to indicate that they recommend adoption, implementation, or deployment of the BIP. Where applicable, the authors must ensure that any proposed specification is solid, not unduly complicated, and definitive. Specification BIPs must come with or refer to a working reference implementation and comprehensive test vectors before they can be moved to Complete. Subsequently, the BIP’s content should only be adjusted in minor details, e.g., to improve language, clarify ambiguities, backfill omissions in the specification, add test vectors for edge cases, or address other issues discovered as the BIP is being adopted. @JeremyRubin: By the way, I asked a couple days ago, whether you would agree that CTV should be Complete rather than Draft. I’m also waiting for your sign-off to publish OP_TWEAKADD.

I'm surprised a consensus change bip was advanced to complete while not including activation parameters. Is the idea that activation parameters would come under the "minimal and interfere as little as possible with ongoing adoption" clause of allowed modifications to a complete bip, or will activation params for bip54 go in a separate bip (similar to 448 vs 446/348/349?), or something else?

Right, the advancing to Complete is about the authors signaling that they have checked off all their planned work items and recommend their idea for adoption. It’s a partial hand-off to the ecosystem. If/when the ecosystem is ready for an attempt to deploy the proposal, the deployment parameters are just a temporary detail of the how. We (I think it was mostly the BIP Editors) had a similar conversation around BIP347 last year, and came to the conclusion that deployment parameters could be added after a BIP was advanced to Complete.

I think that's a little unsatisfactory; I would think a COMPLETE BIP would mean "if you have any copy of this document, you can implement the thing correctly"... Allowing major consensus changes/deployment params after the fact (including we set it to X date and then changed it to Y date) seems like a slight disaster recipe?

Having a Separate Deployment Params BIP which stays incomplete till buried seems better?

Might be worthwhile to publish the rationale of the internal editors chat...

Right, the advancing to Complete is about the authors signaling that they have checked off all their planned work items and recommend their idea for adoption. It’s a partial hand-off to the ecosystem. If/when the ecosystem is ready for an attempt to deploy the proposal, the deployment parameters are just a temporary detail of the how. We (I think it was mostly the BIP Editors) had a similar conversation around BIP347 last year, and came to the conclusion that deployment parameters could be added after a BIP was advanced to Complete.

That doesn't really feel entirely sensible to me, fwiw -- if the idea is to hand off a completed proposal to the "ecosystem" who will choose how to activate it independently of the authors, that reads to me as that the activation params aren't being managed by the proposal authors and should therefore be under a different bip. That could be done as something like bip-0009/bip-0054-202605.md or bip-0054/activation-202605.md or similar, perhaps, to avoid introducing new bip numbers. Associating it with the bip defining how to judge activation would be convenient for activating multiple bips at once, perhaps. That would also make it logical to add buried deplyoment details to bip 90, or similar perhaps.

I did not suggest that the BIP owners should not be involved after a BIP is advanced to complete: I wrote “a partial hand-off”. What I meant was that by advancing to Complete, BIP owners signal that they have finished their planned work on the Specification, Reference Implementation, and Test Vectors, and consider their proposal sufficiently mature for adoption (for non-forks) or for a conversation about activation to happen. Obviously, the ecosystem may still review and provide feedback after that point—which would only be natural to come up when projects implement the proposal—and preferably the BIP owners should continue to be involved and advocate for their proposal if they want to see it adopted.

Once a BIP reaches Complete, further changes need to be recorded in the Changelog and would result in corresponding bumps of the Version header. Adding activation parameters for a deployment attempt would obviously be recorded in that manner. A separate activation BIP also sounds acceptable, especially when multiple BIPs are intended to be deployed as a bundle.

It makes more sense to me that soft fork proposals with fully fleshed out Specification, Reference Implementation, and Test Vectors be advanced to Complete to await activation attempts than to be relegated to Draft.

That could be done as something like bip-0009/bip-0054-202605.md or bip-0054/activation-202605.md or similar

Perhaps keeping track of on-going activation attempts in one place would be a good idea, but I am not sure that a auxiliary file directory would be visible enough, but we could of course update our directory structure to surface such information better, or perhaps add a Process BIP with the purpose of tracking activation attempts.