Split BIP54 into bundle constituents #2175

This is largely an editorial question for the BIP Editors, although authors of BIP 54 may care... Largely looking for approach ack at this step before I do a more careful conformance check that there are no semantic changes from splitting.

It likely makes sense to split-out the fixes proposed in 54 into some constituent BIPs and assign a number. e.g. see https://x.com/satofishi/status/2040424065630953933 for request to have each change have a separate BIP.

That also has a long term benefit of being able to refer to specific changes as BIP-TBD-1 compliance.

Conservatively, I chose to preserve authorship of the sub-bips (except for @Christewart's BIP-53) by attributing the new BIPs to 54's authors, and marking them COMPLETE to preserve 54's complete status.

Alternatively, I could put forth new BIPs (under my or other authoriship?) and later BIP-54 could later be pared down to REQUIRES these?

some other links/comments supportive of splitting:

• #1800#pullrequestreview-2785335249
• #1800#pullrequestreview-2788772574
• #1800 (comment)

Against:

• #1800 (comment)
• #1800#pullrequestreview-2791514520

Concept ACK

As I wrote in #1800#pullrequestreview-2788772574, I'd prefer to see separate, focused BIPs, as recommended in both BIP 2 and BIP 3.

BIP 2: It is highly recommended that a single BIP contain a single key proposal or new idea. The more focused the BIP, the more successful it tends to be. If in doubt, split your BIP into several well-focused ones.

BIP 3: It is recommended that complicated proposals be split into separate BIPs that each focus on a specific component of the overall proposal.

NACK

You are free to make your own BIP, or BIPs, with another proposal (or set of proposals). But it's not appropriate to significantly edit the BIP that was proposed by other authors just because you dislike it, no matter how strongly you feel

BIP 3: It is recommended that complicated proposals be split into separate BIPs that each focus on a specific component of the overall proposal.

I think the complexity and scope of these changes relative to something like Segwit or Taproot (which have multiple associated BIPs) is much more narrow and does not justify a split.

Regardless, given how far along this BIP is and how long the public discussion has been ongoing, changing the BIP (at what is effectively the 11th hour) this drastically is unreasonable. It seems sensible for a competing proposal to have its own BIP entirely, even if it simply removes or changes a single component of BIP 54. It also allows the community a more clear path towards comparing these proposals.

BIP 54 bundles together four items related in that they are minimal fixes for long term bugs in the consensus protocol. This is a complete document that describes a consistent set of changes that we (the authors) propose to the Bitcoin community. I understand that you favour a different mitigation for one of these bugs, but i would ask you to propose it to the Bitcoin community by authoring your own BIP rather than by modifying our own. Therefore NACK on this PR as it stands.

As you point out, the modification you’re suggesting was already discussed before this proposal was published over a year ago. As you are aware, the authors explicitly declined to adopt this suggestion then. At this point it is clear that this suggestion does not match the BIP authors’ intended proposition.

Alternatively, I could put forth new BIPs (under my or other authoriship?) and later BIP-54 could later be pared down to REQUIRES these?

It is up to the authors of BIP54 to decide what they want to put forth to the community. Please submit your own proposal, instead of trying to take control of the scope of an existing proposal.

Can the BIP editors at large get consensus on this and report back? This is a request for feedback on proper approach, so I want to be sure that the BIP editors actually are in agreement in how this BIP should be formatted.

At this point it is clear that this suggestion does not match the BIP authors’ intended proposition It is up to the authors of BIP54 to decide what they want to put forth to the community. Please submit your own proposal, instead of trying to take control of the scope of an existing proposal.

I don't think your characterization here makes any sense. This is a formatting question. Please show me the functional or process changes that this formatting change has?

This is largely an editorial question, and the patch as written doesn't take control of anything given that it preserves authorship (other than @Christewart -- although i suppose we could make an independent copy of BIP-53 to have Antoine and Matt's name on it) and preserves COMPLETE status...

Lastly, the BIPs repo does not have an Issues tab. I'm sensing a lot of hostility here -- which I do not find appropriate -- when really this is posed as a question. An Issues tab would allow for discussion of such things without opening a demonstrative PR.

I don't think your characterization here makes any sense. This is a formatting question

BIP54 is the BIP proposed by its two authors. It is formatted correctly

As discussed multiple times, you are free to make your own BIP or BIP(s)

I’m only speaking for myself, other BIP Editors speak for themselves.

This is a formatting question.

A proposal is predominantly owned by the authors in Draft and Complete status. This proposal has been under active research and development for more than two-and-a-half years, steadily progressing and addressing feedback. It had been published in Draft status for over a year, was recently deployed to signet, and hasn’t changed significantly in months. It should be no surprise that this proposal, after it has test vectors, a reference implementation, is deployed on Signet, and aspects of it were recently demonstrated there, has reached a point where the authors have finished their planned work and recommend it for adoption.

The BIP Authors have indicated that they want to put forth BIP54 as presented. A significant change to the specification would call for a new BIP anyway, so if you favor a different bundle, please submit a new BIP.

@JeremyRubin Given the BIP 54 author disagrees with this proposed modification to BIP 54, there's no point in keeping it open. Edit: If you work something out with the author(s) that they like and wish to push an update here, I’m happy to reopen it.

I agree that the path at this point is to propose the unbundling or combination that you envision, in your own words as your own work, via the usual process as detailed in the README and BIP 3.

Lastly, the BIPs repo does not have an Issues tab. An Issues tab would allow for discussion of such things without opening a demonstrative PR.

(There may be other reasons, but one hypothesis amongst the BIP editors as to why there is no Issues tab, was that the idea was to have those discussions take place on the mailing list.)

@murchandamus i think you're confused that this patch set represents any change to BIP-54...

As per the first paragraph:

conformance check that there are no semantic changes from splitting

so

A significant change to the specification would call for a new BIP anyway, so if you favor a different bundle, please submit a new BIP.

is unrelated to this patch set

While it could be restructured that the Specification in sum would not change, it would create additional work for the authors of BIP54 and likely revert some of the progress they have made in the eyes of the ecosystem.

That's a speculative matter of opinion at best; the opposite could very readily be true as well.