From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D45C83EE for ; Sun, 28 May 2017 20:51:53 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out01.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CBC9513B for ; Sun, 28 May 2017 20:51:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101]) by mx-out01.mykolab.com (Postfix) with ESMTPS id 2B876601BC for ; Sun, 28 May 2017 22:51:49 +0200 (CEST) From: Tom Zander To: bitcoin-dev@lists.linuxfoundation.org Date: Sun, 28 May 2017 22:51:46 +0200 Message-ID: <1729851.ePRgbNd32q@strawberry> In-Reply-To: References: <16817995.6UCILLkEDc@strawberry> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 28 May 2017 20:56:34 +0000 Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 May 2017 20:51:54 -0000 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