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

On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote:
> > why?
>=20
> 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.=20

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 mean=
=20
they can=E2=80=99t operate properly when SW is activated (via bit 4) but th=
ey don=E2=80=99t=20
know its activated (since they only look at bit1), then just ban them when=
=20
they misbehave.
And tell people to upgrade to a version where SegWit is less buggy.

> 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 activatio=
n=20
codepaths and just picking **one**.

You can safely replace the bit1 activation code with a bit4 activation=20
logic, which is based on 80% and has no end-date.
We both know that the bip9 (bit1) based activation will not trigger before=
=20
the expiration date anyway.

These worries are rather trivial to solve if you do a little bit of proper=
=20
architecture of the solution.  This honestly can=E2=80=99t be a reason for =
saying NO=20
to the majority of the mining hash power giving you a break and offering a=
=20
better SegWit activation.

=2D-=20
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel