Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal

From: Erik Aronesty <earonesty@gmail•com>
To: James Hilliard <james.hilliard1@gmail•com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	CalvinRechner <calvinrechner@protonmail•com>
Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
Date: Mon, 29 May 2017 18:52:36 -0400	[thread overview]
Message-ID: <CAJowKgJxCZruMKVESTbguWHDx5Y+KqJKUYDbiv+ZU_SvPdE3Ow@mail.gmail.com> (raw)
In-Reply-To: <CADvTj4q2r7sxXfgkdXjgSD5KaEW010aLq8c3YBvqs50FM_ExGg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 10725 bytes --]

I can't think of any resistance to this, but the code, on a tight timeline,
isn't going to be easy.   Is anyone volunteering for this?

On May 29, 2017 6:19 AM, "James Hilliard via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> For the reasons listed
> here(https://github.com/bitcoin/bips/blob/master/bip-
> 0091.mediawiki#Motivation)
> you should have it so that the HF can not lock in unless the existing
> BIP141 segwit deployment is activated.
>
> The biggest issue is that a safe HF is very unlikely to be able to be
> coded and tested within 6 months.
>
> On Sun, May 28, 2017 at 8:18 PM, CalvinRechner via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > 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 <calvinrechner@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
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 13889 bytes --]