This proposal is written under the assumption that the signatories to the
Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms of the
agreement, and intend to enact the updates described therein. As such,
criticisms pertaining to the chosen deployment timeline or hard fork upgrade
path should be treated as out-of-scope during the initial discussion of this
proposal.
Because it includes the activation of a hard fork for which community consensus
does not yet exist, this proposal is not likely to be merged into Bitcoin Core
in the immediate future, and must instead be maintained and reviewed in a
separate downstream repository. However, it is written with the intent to
remain cleanly compatible with future network updates and changes, to allow for
the option of a straightforward upstream merge if community consensus for the
proposal is successfully achieved in the following months.
<pre>
BIP: ?
Layer: Consensus
Title: Compatibility-oriented omnibus proposal
Author: Calvin Rechner <calvinrech...@protonmail.com>
Comments-Summary: No comments yet.
Comments-URI: ?
Status: Draft
Type: Standards Track
Created: 2017-05-28
License: PD
</pre>
===Abstract===
This document describes a virtuous combination of James Hilliard’s “Reduced
signalling threshold activation of existing segwit deployment”[2], Shaolin
Fry’s “Mandatory activation of segwit deployment”[3], Sergio Demian Lerner’s
“Segwit2Mb”[4] proposal, Luke Dashjr’s “Post-segwit 2 MB block size
hardfork”[5], and hard fork safety mechanisms from Johnson Lau’s
“Spoonnet”[6][7] into a single omnibus proposal and patchset.
===Motivation===
The Consensus 2017 Scaling Agreement[1] stipulated the following commitments:
• Activate Segregated Witness at an 80% threshold, signaling at bit 4
• Activate a 2 MB hard fork within six months
This proposal seeks to fulfill these criteria while retaining maximum
compatibility with existing deployment approaches, thereby minimizing the risks
of a destructive chain split. Additionally, subsequent indications of implied
criteria and expectations of the Agreement[8][9] are satisfied.
The proposed hard fork incorporates a legacy witness discount and 2MB blocksize
limit along with the enactment of Spoonnet-derived protectionary measures, to
ensure the safest possible fork activation within the constraints of the
requirements outlined in the Scaling Agreement.
===Rationale===
To the extent possible, this represents an effort at a best-of-all-worlds
proposal, intended to provide a common foundation from which all
mutually-inclusive goals can be achieved while risks are minimized.
The individual constituent proposals include the following respective
rationales:
James Hilliard’s “Reduced signalling threshold activation of existing segwit
deployment”[2] explains:
> The goal here is to minimize chain split risk and network disruption while
> maximizing backwards compatibility and still providing for rapid activation
> of segwit at the 80% threshold using bit 4.
Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included to:
> cause the existing "segwit" deployment to activate without needing to release
> a new deployment.
Both of the aforementioned activation options (“fast-activation” and “flag-day
activation”) serve to prevent unnecessary delays in the network upgrade
process, addressing a common criticism of the Scaling Agreement and providing
an opportunity for cooperation and unity instead.
Sergio Demian Lerner’s “Segwit2Mb”[4] proposal explains the reasoning behind
linking SegWit’s activation with that of a later hard fork block size increase:
> Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB block
> size hard-fork activated ONLY if segwit activates (95% of miners signaling
> ... to re-unite the Bitcoin community and avoid a cryptocurrency split.
Luke Dashjr’s “Post-segwit 2 MB block size hardfork”[5] suggestions are
included to reduce the marginal risks that such an increase in the block size
might introduce:
> if the community wishes to adopt (by unanimous consensus) a 2 MB block size
> hardfork, this is probably the best way to do it right now... Legacy Bitcoin
> transactions are given the witness discount, and a block size limit of 2 MB
> is imposed.
Johnson Lau’s anti-replay and network version updates[6][7] are included as
general hard fork safety measures:
> In a blockchain split, however, since both forks share the same historical
> ledger, replay attack would be possible, unless some precautions are taken.
===Copyright===
This document is placed in the public domain.
===Specification===
###Proposal Signaling###
The string “COOP” is included anywhere in the txn-input (scriptSig) of the
coinbase-txn to signal compatibility and support.
###Soft Fork###
Fast-activation (segsignal): deployed by a "version bits" with an 80%
activation threshold BIP9 with the name "segsignal" and using bit 4... [with a]
start time of midnight June 1st, 2017 (epoch time 1496275200) and timeout on
midnight November 15th 2017 (epoch time 1510704000). This BIP will cease to be
active when segwit is locked-in.[2]
Flag-day activation (BIP148): While this BIP is active, all blocks must set the
nVersion header top 3 bits to 001 together with bit field (1<<1) (according to
the existing segwit deployment). Blocks that do not signal as required will be
rejected... This BIP will be active between midnight August 1st 2017 (epoch
time 1501545600) and midnight November 15th 2017 (epoch time 1510704000) if the
existing segwit deployment is not locked-in or activated before epoch time
1501545600. This BIP will cease to be active when segwit is locked-in. While
this BIP is active, all blocks must set the nVersion header top 3 bits to 001
together with bit field (1<<1) (according to the existing segwit deployment).
Blocks that do not signal as required will be rejected.[3]
###Hard Fork###
The hard fork deployment is scheduled to occur 6 months after SegWit activates:
(HardForkHeight = SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280)
For blocks equal to or higher than HardForkHeight, Luke-Jr’s legacy witness
discount and 2MB limit are enacted, along with the following Spoonnet-based
improvements[6][7]:
* A "hardfork signalling block" is a block with the sign bit of header nVersion
is set [Clearly invalid for old nodes; easy opt-out for light wallets]
* If the median-time-past of the past 11 blocks is smaller than the
HardForkHeight... a hardfork signalling block is invalid.
* Child of a hardfork signalling block MUST also be a hardfork signalling block
* Hardfork network version bit is 0x02000000. A tx is invalid if the highest
nVersion byte is not zero, and the network version bit is not set.
===Deployment===
Deployment of the “fast-activation” soft fork is exactly identical to
Hilliard’s segsignal proposal[2]. Deployment of the “flag-day” soft fork is
exactly identical to Fry’s BIP148 proposal[3]. HardForkHeight is defined as
26280 blocks after SegWit is set to ACTIVE. All blocks with height greater than
or equal to this value must adhere to the consensus rules of the 2MB hard fork.
===Backwards compatibility===
This deployment is compatible with the existing "segwit" bit 1 deployment
scheduled between midnight November 15th, 2016 and midnight November 15th, 2017.
To prevent the risk of building on top of invalid blocks, miners should upgrade
their nodes to support segsignal as well as BIP148.
The intent of this proposal is to maintain full legacy consensus compatibility
for users up until the HardForkHeight block height, after which backwards
compatibility is waived as enforcement of the hard fork consensus ruleset
begins.
===References===
[1]
https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.html
[3] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921.html
[5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014399.html
[6]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
[7]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013473.html
[8] https://twitter.com/sysmannet/status/867124645279006720
[9] https://twitter.com/JihanWu/status/867139046786465792
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
