See Calvin Rechner's BIP: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal.
Signalling is via the string "COOP."
Here is some of the BIP in question:
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.
...
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.
I will expound upon this later, but I support this proposal. Primarily because it includes BIP148 UASF, secondarily because it includes a 2mB blocksize increase, which I support in principle (I am a big blocker but opposed to divergent consensus.)
Submitted May 29, 2017 at 12:59PM by AltF http://bit.ly/2r3POeP
No comments :
Post a Comment