Date: Fri, 26 May 2017 22:44:44 +0000
In-Reply-To: <CADvTj4o2pFXZFHALfP-dJ10+AQxfFLVuohcpBn-tupf+CHRBYA@mail.gmail.com>
References: <CAAUaCyiHUOQ-rhN5XiGyMc6ocfsNBuH_tzK_QWu7sg1=Qd-o=Q@mail.gmail.com>
	<9e2e7009-7bec-845a-bc9f-3ee03d4b4e7f@mattcorallo.com>
	<CAAUaCyj1Yo+CpmwR40U711wknwerYeE_WkLERHuKf3uX-fcQjA@mail.gmail.com>
	<CADvTj4o2pFXZFHALfP-dJ10+AQxfFLVuohcpBn-tupf+CHRBYA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: James Hilliard <james.hilliard1@gmail.com>,
	Jacob Eliosoff <jacob.eliosoff@gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <18D47015-A4F0-438C-8D46-812E3F20EE2B@mattcorallo.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement
Precedence: list

While I'm not 100% convinced there are strict technical reasons for needing=
 to wait till after segwit is active before a hard fork can be started (you=
 can, after all, activate segwit as a part of the HF), there are useful des=
ign and conservatism reasons (not causing massive discontinuity in fee mark=
et, handling major system changes one at a time, etc)=2E

Still, totally agree that attempting to design, code, and test a new hard =
fork in six months, let alone deploy it, let alone simultaneously with segw=
it, is a joke and fails to take seriously the investment many have made in =
the bitcoin system=2E Previous, rather simple, soft forks required similar =
if not more development time, not counting deployment and activation time=
=2E

If the community is unable to form consensus around segwit alone for polit=
ical reasons, further research into hard fork design may help, but even for=
ks tied together would nearly certainly need to activate months apart=2E

On May 26, 2017 5:30:37 PM EDT, James Hilliard <james=2Ehilliard1@gmail=2E=
com> wrote:
>Mandatory signalling is the only way to lock in segwit with less than
>95% hashpower without a full redeployment(which for a number of
>technical reasons isn't feasible until after the existing segwit
>deployment expires)=2E There's no reason not to signal BIP141 bit 1
>while also signalling bit 4, but you would want to use bit 4 to
>coordinate bit 1 mandatory signalling=2E
>
>It would not be feasible to schedule any HF until one can be
>completely sure BIP141 is active(at least not without waiting for the
>timeout and doing a redeployment) due to activation/p2p codepath
>complexity=2E This is why the mandatory signalling period is needed=2E
>
>Since it is likely a HF will take months of development and testing I
>see this or something similar as the fastest safe path forward:
>1=2E Use BIP91 or similar to activate BIP141 via mandatory signalling
>ASAP(likely using bit 4)
>2=2E Develop HF code based on assumption that BIP141 is active so that
>you only have to test the BIP141->HF upgrade/activation codepath=2E
>3=2E Deploy HF after BIP141 lock in(bit 4 can be reused again here since
>this will be after BIP91 expiration)
>
>When rolling out some features it often makes sense to combine them
>into a single fork for example BIP's 68, 112, 113 were rolled out at
>the same time as are BIP's 141, 143, 144, 145 for segwit, however a HF
>has required features that would conflict with with features in the
>segwit rollout which is why attempting to simultaneously deploy them
>would cause major complexity/testing issues(you would have to deal
>with feature conflict resolution for multiple potential activation
>scenarios)=2E By doing a staged rollout of segwit and then a HF you get
>a single testable upgrade path=2E
>
>Based on past development experiences I wouldn't expect a 6 month
>timeline to be realistic for a properly tested HF, but this proposed
>upgrade path should be the fastest available for both SegWit and a HF
>regardless=2E
>
>On Fri, May 26, 2017 at 4:10 PM, Jacob Eliosoff via bitcoin-dev
><bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrote:
>> Just to clarify one thing, what I described differs from BIP91 in
>that
>> there's no orphaning=2E  Just when Segwit2MB support reaches 80%, those
>80%
>> join everyone else in signaling for BIP141=2E  BIP91 orphaning is an
>optional
>> addition but my guess is it wouldn't be needed=2E
>>
>>
>> On May 26, 2017 4:02 PM, "Matt Corallo" <lf-lists@mattcorallo=2Ecom>
>wrote:
>>>
>>> Your proposal seems to be simply BIP 91 tied to the
>>> as-yet-entirely-undefined hard fork Barry et al proposed=2E
>>>
>>> Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal,
>as
>>> you propose, would make the deployment on the incredibly short
>timeline
>>> Barry et al proposed slightly more realistic, though I would expect
>to
>>> see hard fork code readily available and well-tested at this point
>in
>>> order to meet that timeline=2E
>>>
>>> Ultimately, due to their aggressive timeline, the Barry et al
>proposal
>>> is incredibly unlikely to meet the requirements of a
>>> multi-billion-dollar system, and continued research into meeting the
>>> spirit, not the text, of their agreement seems warranted=2E
>>>
>>> Matt
>>>
>>> On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote:
>>> > Forgive me if this is a dumb question=2E  Suppose that rather than
>>> > directly activating segwit, the Silbert/NYC Segwit2MB proposal's
>lock-in
>>> > just triggered BIP141 signaling (plus later HF)=2E  Would that avoid
>>> > incompatibility with existing BIP141 nodes, and get segwit
>activated
>>> > sooner?  Eg:
>>> >
>>> > - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals
>support
>>> > for "segwit now, HF (TBD) at scheduled date (Nov 23?)"
>>> > - If bit 4 support reaches 80%, it locks in two things: the
>scheduled HF
>>> > (conditional on segwit), and *immediately* turning on bit 1
>(BIP141
>>> > support)
>>> >
>>> > I realize this would still leave problems like the aggressive HF
>>> > schedule, possible chain split at the HF date between Segwit2MB
>nodes
>>> > and any remaining BIP141 nodes, etc=2E  My focus here is how
>>> > incompatibility with existing nodes could be minimized=2E
>>> >
>>> > (BIP91 could also be used if BIP141 support still fell short of
>95%=2E
>>> > But if Segwit2MB support reaches 80%, it seems likely that an
>additional
>>> > 15% will support BIP141-without-HF=2E)
>>> >
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev@lists=2Elinuxfoundation=2Eorg
>>> > https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev
>>> >
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists=2Elinuxfoundation=2Eorg
>> https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev
>>