I believe this is ready for BIP number assignment?
New BIP: P2SH and Version 0 Segwit Script enforcement from genesis #638
pull sdaftuar wants to merge 1 commits into bitcoin:master from sdaftuar:p2sh-v0segwit-from-genesis changing 1 files +108 −0-
sdaftuar commented at 6:33 PM on January 29, 2018: member
-
draft bip for extending p2sh/segwit v0 script rules to genesis block 366419ca8e
- luke-jr cross-referenced this on Jan 30, 2018 from issue Remove 'hard fork' designation on BIP 90 by sdaftuar
-
-
MarcoFalke commented at 1:28 PM on January 30, 2018: member
-
sdaftuar commented at 1:46 PM on January 30, 2018: member
On further thought, we can wait on BIP number assignment for now, if the PR to Bitcoin Core isn't merged then I'll just withdraw this.
-
luke-jr commented at 3:22 PM on January 30, 2018: member
@MarcoFalke That doesn't address the question of whether to make BIPs for "technically a protocol change, but has no actual effect on the chain present or future".
-
evoskuil commented at 10:31 PM on January 30, 2018: contributor
Would the plan then be to document soft forks only after miners have actually rejected blocks by enforcing them?
-
MarcoFalke commented at 11:59 PM on January 30, 2018: member
Talking about protocol upgrades, whether they are soft forks or hard forks, clearly they should be documented.
-
evoskuil commented at 12:05 AM on January 31, 2018: contributor
That was my point, we don’t wait until there is a split to document a fork, we do it well beforehand. So the occurance of a split cannot be a threshold criteria.
Upgrade is a loaded term, implying that there are other deviations that do not need to be documented. If the purpose of the documentation is to document the protocol, any deviation from the protocol needs to be documented.
-
sdaftuar commented at 1:38 PM on April 18, 2018: member
Closing in favor of @luke-jr's suggestion here: #639 (comment)
- sdaftuar closed this on Apr 18, 2018
Contributors