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 D98329C for ; Sun, 28 May 2017 23:28:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3B934F3 for ; Sun, 28 May 2017 23:28:12 +0000 (UTC) Received: by mail-oi0-f41.google.com with SMTP id w10so62213838oif.0 for ; Sun, 28 May 2017 16:28:12 -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=cKqY2Y1nD1kCcdlBlW8kTdEmcaFxkNtjFBUkNox0wvo=; b=rlGgQtlnvyWgxgkkZjGu1eEqok/LBbFTRbD6YPmB1ZwWiTuJQROGbpl0OBO46z+EqV SaTYF9Sqy6+I0gVPldKNJv6wpzOZBvlQJhCy/XswQmkI49kLlXtqKIM2+F98/RSG0O7T l1JmxJKk6eIVDX8gduUjBarDhZDbTMg7L8v4/mF6rL/mTd9oxebF7V2QyRn8A/TZDOV8 6jlnzf2QXkETZgym2kzHMA+woqlCc+Nq0jYsLrH1YeHc+eGAYx/tA+iBGxKSnGn5K+yg 9wt2CeUQwprIeOCw+z5pnlEJed8hv3hGZHCrOKhU4KKuQd420+mRTIMQ+EltIJVuWSyW Hh0Q== 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=cKqY2Y1nD1kCcdlBlW8kTdEmcaFxkNtjFBUkNox0wvo=; b=jCLLZA4mjGrbROJQUsyMfPst8EEcAZIWWRd9LYSKYme6/NUo+dDnsPOsSdrV8LO1mM 62hwAhwqkW6iuX+kAuiHjjyC7vFPU0r8qcXGJuNGLasiyZpG/TQ9BmSGsZPbjJd0F3Ei VzvyyHKszOMjqm6MSCzXppyLM5B9EvQU2BT68/1zFwsvnLl3VUbqRqMfKR3tzKZGQG6/ 50x72Qq3b0pAIcoEJfZnlZaIw50Nl0s3EG7S1rZyWMT2aS2rlNFi+ZQg7KGsS/rGZxSP WkEgG8Fc8Zh+8qLsIY0Qg24L5I1B6GTY1yqkAzLqvOPkhp5lep8GpLaVdncvxVOCe/ay y/ZA== X-Gm-Message-State: AODbwcAFOQAMzLRK7xLB1Km5EEqgHj5KbqN08lVKH+83qIf/zNPkEMDR o3EKzsIQbBH9X0n8MdFnxciEcsa/Ug== X-Received: by 10.202.196.83 with SMTP id u80mr4809216oif.207.1496014091495; Sun, 28 May 2017 16:28:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.115.198 with HTTP; Sun, 28 May 2017 16:28:11 -0700 (PDT) In-Reply-To: <1729851.ePRgbNd32q@strawberry> References: <16817995.6UCILLkEDc@strawberry> <1729851.ePRgbNd32q@strawberry> From: James Hilliard Date: Sun, 28 May 2017 18:28:11 -0500 Message-ID: To: Tom Zander 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 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 23:28:13 -0000 On Sun, May 28, 2017 at 3:51 PM, Tom Zander via bitcoin-dev 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