path: root/fd/15df55e24d0ae80c3ad36f391e595265812fa9

Return-Path: <james.hilliard1@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F0B0F3EE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 May 2017 10:19:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com
	[209.85.218.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10101F3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 May 2017 10:19:19 +0000 (UTC)
Received: by mail-oi0-f45.google.com with SMTP id b204so73993201oii.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 May 2017 03:19:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-transfer-encoding;
	bh=xYKvZs09GU2VML1pR/jO7BfZOmeWZJ6pPLJa2Pl5F58=;
	b=CDtkVabHgocLD2YMjVoNV2Yx/QaIRfDASxxwCZgo1Lnpsy/aJyoRfuJknvEFD6G9TR
	h4uLrkmF0zED3unYYkAkOmcqq7RD5DqKPKI+r/VMMlk6pukCfYUnFnpNC1StxrRylBqd
	oSnPYfrXLVZwy8czlOs1OiS2LUrlczfN+rJD0z4BTqSBDAvq62qOP1XM9ZxR/bf1gfK5
	6IdvKZi0802L2oG2LLvB29oEPq70yLI/LoT+3D2/ogK1mQaVyvKHrzFBxxtFxI9xuHnR
	SO/swqPSvKe+GZ/L9QNNOHQeMQ2l4KaaROM/Qn/8c3+f66uX6iPlS13hv7gTF3bwvrq6
	ud1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-transfer-encoding;
	bh=xYKvZs09GU2VML1pR/jO7BfZOmeWZJ6pPLJa2Pl5F58=;
	b=hO+/91na3r1mSXxN/2hMl+Flvro8L3DthoTregMgT0LaH/I5Wce/i1FbPaWF8AAB8T
	O9WF5RoDd4JOusbygBzmCmkBDrQHMex60MpNi6uSotcAutJ4GHbdQ625PVULin5QhOZ3
	GCts1qoHrURU/Jb7e4O1MesPl9PfDL0b3zRYzE2qjftK9N05hCAmeg+NbqDxAq9A90DV
	tdITjXr0BA7kOkFLBv7ebiAUAfsixzOMtIPLXxG3qEo69lcy8fgKOW98+8sI8Zj4bG+v
	B8ovLRMXTrBTWNMfaPdv6/lwkOZ6JfscL63go9sAugOYdGIuv2SNnKajBQIn3iKbtahb
	MZ1A==
X-Gm-Message-State: AODbwcBvOGpt8Ne5bihXV52Uh9oVM3dyj4Hs+tdNZzH3vVbR3Uw8Vl73
	ejxbth3+WPndkW3x4jIvU9KvVYjKzQ==
X-Received: by 10.157.14.230 with SMTP id 93mr7912479otj.97.1496053159157;
	Mon, 29 May 2017 03:19:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.115.198 with HTTP; Mon, 29 May 2017 03:19:18 -0700 (PDT)
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
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 29 May 2017 10:19:21 -0000

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
>