MIME-Version: 1.0
In-Reply-To: <aC4avUiJPnHXxIxPlh4w2XA-SLB6ueTUlVTW7TreFwGV12L7L9CAGoB2E9msVYhV0M6xPTERpatAIeZO3kK-ikCRkwYQcJeEMHS7WWZKDAM=@protonmail.com>
References: <aC4avUiJPnHXxIxPlh4w2XA-SLB6ueTUlVTW7TreFwGV12L7L9CAGoB2E9msVYhV0M6xPTERpatAIeZO3kK-ikCRkwYQcJeEMHS7WWZKDAM=@protonmail.com>
From: James Hilliard <james.hilliard1@gmail.com>
Date: Mon, 29 May 2017 05:19:18 -0500
Message-ID: <CADvTj4q2r7sxXfgkdXjgSD5KaEW010aLq8c3YBvqs50FM_ExGg@mail.gmail.com>
To: CalvinRechner <calvinrechner@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
Precedence: list

For the reasons listed
here(https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki#Motivat=
ion)
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 upgr=
ade
> path should be treated as out-of-scope during the initial discussion of t=
his
> 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 in=
to
> 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>
>
>
> =3D=3D=3DAbstract=3D=3D=3D
>
> This document describes a virtuous combination of James Hilliard=E2=80=99=
s =E2=80=9CReduced
> signalling threshold activation of existing segwit deployment=E2=80=9D[2]=
, Shaolin
> Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployment=E2=80=9D=
[3], Sergio Demian Lerner=E2=80=99s
> =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal, Luke Dashjr=E2=80=99s =E2=80=9CP=
ost-segwit 2 MB block size
> hardfork=E2=80=9D[5], and hard fork safety mechanisms from Johnson Lau=E2=
=80=99s
> =E2=80=9CSpoonnet=E2=80=9D[6][7] into a single omnibus proposal and patch=
set.
>
>
> =3D=3D=3DMotivation=3D=3D=3D
>
> The Consensus 2017 Scaling Agreement[1] stipulated the following
> commitments:
>
> =E2=80=A2 Activate Segregated Witness at an 80% threshold, signaling at b=
it 4
> =E2=80=A2 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 protectionar=
y
> measures, to ensure the safest possible fork activation within the
> constraints of the requirements outlined in the Scaling Agreement.
>
>
> =3D=3D=3DRationale=3D=3D=3D
>
> 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=E2=80=99s =E2=80=9CReduced signalling threshold activation=
 of existing segwit
> deployment=E2=80=9D[2] explains:
>
>> The goal here is to minimize chain split risk and network disruption whi=
le
>> maximizing backwards compatibility and still providing for rapid activat=
ion
>> of segwit at the 80% threshold using bit 4.
>
> Shaolin Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployment=
=E2=80=9D[3] is included to:
>
>> cause the existing "segwit" deployment to activate without needing to
>> release a new deployment.
>
> Both of the aforementioned activation options (=E2=80=9Cfast-activation=
=E2=80=9D and
> =E2=80=9Cflag-day activation=E2=80=9D) serve to prevent unnecessary delay=
s in the network
> upgrade process, addressing a common criticism of the Scaling Agreement a=
nd
> providing an opportunity for cooperation and unity instead.
>
> Sergio Demian Lerner=E2=80=99s =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal ex=
plains the reasoning behind
> linking SegWit=E2=80=99s 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 blo=
ck
>> size hard-fork activated ONLY if segwit activates (95% of miners signali=
ng
>> ... to re-unite the Bitcoin community and avoid a cryptocurrency split.
>
> Luke Dashjr=E2=80=99s =E2=80=9CPost-segwit 2 MB block size hardfork=E2=80=
=9D[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... Legac=
y
>> Bitcoin transactions are given the witness discount, and a block size li=
mit
>> of 2 MB is imposed.
>
> Johnson Lau=E2=80=99s anti-replay and network version updates[6][7] are i=
ncluded as
> general hard fork safety measures:
>
>> In a blockchain split, however, since both forks share the same historic=
al
>> ledger, replay attack would be possible, unless some precautions are tak=
en.
>
>
> =3D=3D=3DCopyright=3D=3D=3D
>
> This document is placed in the public domain.
>
>
> =3D=3D=3DSpecification=3D=3D=3D
>
> ###Proposal Signaling###
>
> The string =E2=80=9CCOOP=E2=80=9D 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... [w=
ith
> a] start time of midnight June 1st, 2017 (epoch time 1496275200) and time=
out
> on midnight November 15th 2017 (epoch time 1510704000). This BIP will cea=
se
> to be active when segwit is locked-in.[2]
>
> Flag-day activation (BIP148): While this BIP is active, all blocks must s=
et
> 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 Aug=
ust
> 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch t=
ime
> 1510704000) if the existing segwit deployment is not locked-in or activat=
ed
> before epoch time 1501545600. This BIP will cease to be active when segwi=
t
> 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 b=
e
> rejected.[3]
>
> ###Hard Fork###
>
> The hard fork deployment is scheduled to occur 6 months after SegWit
> activates:
>
> (HardForkHeight =3D SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280)
>
> For blocks equal to or higher than HardForkHeight, Luke-Jr=E2=80=99s lega=
cy witness
> discount and 2MB limit are enacted, along with the following Spoonnet-bas=
ed
> 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 high=
est
> nVersion byte is not zero, and the network version bit is not set.
>
>
> =3D=3D=3DDeployment=3D=3D=3D
>
> Deployment of the =E2=80=9Cfast-activation=E2=80=9D soft fork is exactly =
identical to
> Hilliard=E2=80=99s segsignal proposal[2]. Deployment of the =E2=80=9Cflag=
-day=E2=80=9D soft fork is
> exactly identical to Fry=E2=80=99s BIP148 proposal[3]. HardForkHeight is =
defined as
> 26280 blocks after SegWit is set to ACTIVE. All blocks with height greate=
r
> than or equal to this value must adhere to the consensus rules of the 2MB
> hard fork.
>
>
> =3D=3D=3DBackwards compatibility=3D=3D=3D
>
> 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.
>
>
> =3D=3D=3DReferences=3D=3D=3D
>
> [1]
> https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133=
521fe9a77
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.h=
tml
> [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.h=
tml
> [6]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013=
542.html
> [7]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/0134=
73.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
>