WITHDRAWN: BUIP100: Ability to disable the "automated replay protection" specified for Nov 2018

[freetrader]

BUIP100: Ability to disable the "automated replay protection" specified for November 2018
Submitted on 25th August 2018 by freetrader

Background
The specification for Bitcoin Cash's May 2018 fork included a "replay protection" requirement [1] which forks compliant full node clients off the network by changing the "forkid" from 0 to 0xFF0001 when the median time past[2] of the most recent 11 blocks (MTP-11) is greater than or equal to UNIX timestamp 1542300000 (November 2018 hardfork).

Effectively this means that Bitcoin Cash, incl. BUcash, client MUST hardfork in November, just to preserve compatibility with wallet software.

This means that simply running an existing compliant full node such as ABC 0.17.x is not sufficient to indicate that you want to "not fork" in November. You would get forked off from the existing wallet ecosystem.

Motivation
Make it a choice in BU to not comply with that rule of the May 2018 specification.
i.e. be able to continue running and remain compatible with the current ecosystem even if you want to vote for no other changes at this time.

Goal
Make "no changes" a valid choice, not requiring a hard fork on BU full nodes, and effectively vote against the policy of 6-monthly hardforks in the future by removing this requirement.

Task
Make code which fulfils this particular requirement in the May specification entirely optional in BU.

Default value
The default value of the option is to break compliance with the May 2018 specification by not forking the replay protection. Rationale is that on Bitcoin Cash, clients usually issue an update prior to the next hard fork which suspends the replay forking until the next HF, whenever that is scheduled.
Not following the requirement is safer than following it, in this case, because it will keep BUcash in sync with the SPV nodes by default.

Timetable
Must be implemented, tested and released at least 2 weeks before timestamp 1542300000.
(This timeframe is subject to debate - please comment on this BUIP!)

Caveats
Must review and test both enabled & disabled pathways carefully, that's about the only one I can think of. Comments welcome.

References
[1] https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/may-2018-hardfork.md#automatic-replay-protection
[2] MTP: the "median time past" value of a block, calculated from its nTime value, and the nTime values of its up to 10 immediate ancestors.

EDITS:

- add default value proposition
- change default value proposition to 'break compliance with the automated replay forking'
- number changed from 99 to 100 (solex)

 

[Christoph Bergmann]

Sounds good.

 

[theZerg]

The BU releases do not and have never implemented thing called "replay protection" by some. If I was going to put a poison pill in the code that forced an upgrade, I would not shock my users by silently forking to an incompatible blockchain and leaving them wondering WTF? Instead I would quit with a nice informational message, and prominently display a "you MUST upgrade" warning for at least 2 months leading up to the shut-off date.

So probably not reason to vote on this BUIP. Since we are still in the "working with the dev" period, you can just retract it (tell me and I'll edit the title).

But if you want an informational vote on this issue, go ahead and keep this as a BUIP. I am saying "informational" because a failed vote does not mean that the membership endorses the BUIP's opposite.

 

[freetrader]

The BU releases do not and have never implemented thing called "replay protection" by some.

I was clear about which "replay protection" I'm discussing in this BUIP:
https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/may-2018-hardfork.md#automatic-replay-protection

I'm personally glad to hear from that BU has not implemented it. At least this BUIP clarified the danger in that part of the specification, and made it clear that BU doesn't follow it.

If I was going to put a poison pill in the code that forced an upgrade, I would not shock my users by silently forking to an incompatible blockchain and leaving them wondering WTF? Instead I would quit with a nice informational message, and prominently display a "you MUST upgrade" warning for at least 2 months leading up to the shut-off date.

That would appear a more sensible approach to me as well, rather than leaving users on an incompatible chain.

So probably not reason to vote on this BUIP. Since we are still in the "working with the dev" period, you can just retract it (tell me and I'll edit the title).

I don't think I need you to edit the title. I was able to edit a submission title myself last time I checked.

But if you want an informational vote on this issue, go ahead and keep this as a BUIP.

No, I don't. I'm no fan of the "informational vote", as I've made clear in my comments to the recent "informational" BUIPs. Either there is a proposal to do fulfil a need, or there isn't.
But this is a separate matter from this BUIP.

I am saying "informational" because a failed vote does not mean that the membership endorses the BUIP's opposite.

I agree with that.
I don't see a need for this BUIP anymore at this time, so I will withdraw it.
[doublepost=1535527513][/doublepost]@solex : I am withdrawing this BUIP as I see no need for code changes, after discussion with @theZerg . I've amended the title, can you please amend as needed in other records (BUIP index). Thanks.

 

[solex]

Thanks for the information @theZerg and @freetrader. I shall effect the withdrawal in the index.

 

[torusJKL]

If I was going to put a poison pill in the code that forced an upgrade, I would not shock my users by silently forking to an incompatible blockchain and leaving them wondering WTF? Instead I would quit with a nice informational message, and prominently display a "you MUST upgrade" warning for at least 2 months leading up to the shut-off date.

I was not aware of this feature in ABC and am very pleased that it was not implemented in BU.

If a user does not update than it is his choice and he should not be silently forced into a different ruleset making the old version practically unusable.