MIME-Version: 1.0
In-Reply-To: <1729851.ePRgbNd32q@strawberry>
References: <CAAUaCyiHUOQ-rhN5XiGyMc6ocfsNBuH_tzK_QWu7sg1=Qd-o=Q@mail.gmail.com>
	<16817995.6UCILLkEDc@strawberry>
	<CADvTj4qdr2yGYFEWA7oVmL-KkrchYb5aQBRY9w0OK4ZVopSTSA@mail.gmail.com>
	<1729851.ePRgbNd32q@strawberry>
From: James Hilliard <james.hilliard1@gmail.com>
Date: Sun, 28 May 2017 18:28:11 -0500
Message-ID: <CADvTj4opFPA1CGaAyuy-qys4qF40ixStntNSWO9_OpbBmTE37g@mail.gmail.com>
To: Tom Zander <tomz@freedommail.ch>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement
Precedence: list

On Sun, May 28, 2017 at 3:51 PM, Tom Zander via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote:
>> > why?
>>
>> the main
>> issue is due to 0.13.1+ having many segwit related features active
>> already, including all the P2P components, the new network service
>> flag, the witness-tx and block messages, compact blocks v2 and
>> preferential peering.
>
> Hmm, the flags are identical in 0.13 and 0.14 clients.
>
> Either way, this is rather trivial to solve. If bugs in older clients mea=
n
> they can=E2=80=99t operate properly when SW is activated (via bit 4) but =
they don=E2=80=99t
> know its activated (since they only look at bit1), then just ban them whe=
n
> they misbehave.
> And tell people to upgrade to a version where SegWit is less buggy.
That would partition off those clients, which is not something we
would want to happen.
>
>> You would have to then have multiple activation
>> codepaths to test for such as BIP141(active)->HF BIP141(inactive)->HF
>> etc. By doing BIP141 first you then only have the BIP141(active)->HF
>> activation codepath to test for, and you also can't be sure you can
>> rely on BIP141(inactive)->HF activation codepath being the only one
>> until segwit activation expires.
>
> Heh, well, this is rather simple to solve by not having all those activat=
ion
> codepaths and just picking **one**.
This isn't possible until either BIP141 segwit is active or BIP141
segwit has expired.
>
> You can safely replace the bit1 activation code with a bit4 activation
> logic, which is based on 80% and has no end-date.
> We both know that the bip9 (bit1) based activation will not trigger befor=
e
> the expiration date anyway.
We don't know that since bip9 bit1 only needs 55% hashpower to be
triggered(see BIP91 activation method for how this can be done)
>
> These worries are rather trivial to solve if you do a little bit of prope=
r
> architecture of the solution.  This honestly can=E2=80=99t be a reason fo=
r saying NO
> to the majority of the mining hash power giving you a break and offering =
a
> better SegWit activation.
BIP91 activation is clearly superior than trying to fully redeploy, it
is far simpler and can be done almost immediately with only miners
needing to upgrade.
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev