Consensus Cleanup Protocol Changes as Independent BIPs

[JeremyRubin]

Add three unassigned Draft BIPs for the timestamp-boundary fix, the legacy sigops transaction limit, and coinbase locktime duplicate prevention. Attribute the new drafts to Jeremy Rubin, leave BIP54 and BIP53 unchanged, and copy each new draft's test vectors into its own auxiliary directory.

As per discussion on #2175 (comment) this seems to be the favored approach.

@Christewart, I think it's worthwhile (separate from this) to make BIP-0053 have the same test vectors and spec languages as BIP-0054 for the 64 byte rule.

[jonatack]

Looks reasonably complete. Is it your intention to propose the same mitigations as BIP54, or a somewhat different set?

[murchandamus]

This does look like a replication of three parts of BIP54. Would I be right to expect another document that bundles either these three parts or these three parts plus an alternative to the 64-byte mitigation? Unless these forthcoming documents were to propose something different than BIP54 in sum, I don’t see the point of splitting BIP54 and duplicating the content.

[JeremyRubin]

Not clear if I intend to bundle them -- I'm tepid about bundling in general. Perhaps just as a deployment BIP?

In the future, I'll propose alternative mitigations for 64-byte witness stripped mitigations.

[SatsAndSports]

What's the ultimate goal here? Is the goal to propose multiple different soft forks, with different activations, for each of the seperate issues?

[JeremyRubin]

well, I'm doing this work because I think removing 64 byte witness stripped transactions from Bitcoin to benefit SPV users is a mistake, and a mistake with better alternatives.

Un-bundling them is "friendly" because I don't want to make unneccessary churn on the other consensus cleanup proposal components.

[SatsAndSports]

... I think removing 64 byte witness stripped transactions from Bitcoin to benefit SPV users is a mistake, and a mistake with better alternatives.

I guess we don't need to know today, but do you have views on activation of the set of changes you propose? If you haven't decided yet, I guess that's fine

Do you envision proposing a single soft fork that activates multiple changes, including your preferred modifications compared to BIP 54 ? Or do you envision proposing multiple (three) separate soft forks, each with their own version bit, potentially signalling in parallel?

Soft fork BIPs are proposed only in order to activate them eventually. It might be confusing in future if you propose a single "activation BIP", defining the version bit and explicit block heights, where that BIP refers to your three separate BIPs

[murchandamus]

Un-bundling them is "friendly" because I don't want to make unneccessary churn on the other consensus cleanup proposal components.

The debundling was discussed a year ago, and BIP54 was subsequently accepted in its current form. If you want to make such decisions in the future, please feel free to throw your hat in the ring for the BIP Editor role.

My point is that just debundling BIP54 does not introduce a novel idea, it only duplicates existing work. So far, this submission does not appear to contain a novel idea nor otherwise diverge from or conflict with existing proposals.

well, I'm doing this work because I think removing 64 byte witness stripped transactions from Bitcoin to benefit SPV users is a mistake, and a mistake with better alternatives.

I am suggesting that you expand this PR by including your idea that conflicts with BIP54 to motivate the debundling. Until this submission contains a novel aspect, I do not consider it ready for review. Please remember that new BIP ideas should be presented in a fresh thread to the mailing list.