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 9B36A9E8 for ; Thu, 6 Jul 2017 17:20:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 06E231BB for ; Thu, 6 Jul 2017 17:20:48 +0000 (UTC) Received: by mail-vk0-f53.google.com with SMTP id r126so4312883vkg.0 for ; Thu, 06 Jul 2017 10:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CgL+jPKqzTsftGK8j4n4lhPbpc5Tbu3tFnIv8Nxyi00=; b=L1uGAOpaTtybKWR98aIPGMSDFEBjUypgQHUowzeRkxpZaUKm/kEuZnDlrVseFjA7n5 +JXITZi09kONXmHXst5gofJny4fMgmbt/F8Uv2DZcg+TLkFcwDSOJAgZDQ0cN/1h7w8Q 7/IpzAxMOpbHdSONp8aErDJOsJFjJXHxRuqCN4istMq6r09c+rEvys33RRMKTuj/Xy7y L+LptesuXcopqbRlT1+DINcisKL8sfK4LLgNOtAOPKz2orYL9fGJc+BtFZXhepR7YXLL u947AajtjbVK5CKYrwPh+9wxOMtgxVK97C9CTmY+B34vbEBH/+++bDVRxOqI/M8LuSyN 3quA== 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=CgL+jPKqzTsftGK8j4n4lhPbpc5Tbu3tFnIv8Nxyi00=; b=crA07YaSL2EAJnye4Gr/BAqwPOVciRlXyzfDhpVocyiJJlmjUiJ1bhX2bQunAMXNDi m4M//pet1oG40YiWObFBRSFHP2UrKHUtf3AE2tYsym5/c6tphdjQstBQFbYb75G3o52s z7o3DujiRwWwQQjswU0l0grgfiBLXVBfQypmxGxXRoaFvokzpnYd/iVlClBCZosWuP6H dT6dsn/f4LRFJ24y2j/Zf1Ua2IEl3YidAk97HYeJ2RvKYLVjWRlloS1pfZg95eNBx+9t onhOoaNCnea/V7TwisSc6JQom8iOZBdbUlAZDC8O19qZNbTaZgiEI9DgVCQpeYED05IT Cg0Q== X-Gm-Message-State: AKS2vOx9qIABLlzAG12d51Qaz9BQBiQJNgCbgiAxh2V6pn6IlBo8BrCr 7Pm+YCh6nrjPdsBRYMyooPAIKppnS3eaAf4= X-Received: by 10.31.89.4 with SMTP id n4mr25488165vkb.135.1499361648066; Thu, 06 Jul 2017 10:20:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.52.85 with HTTP; Thu, 6 Jul 2017 10:20:47 -0700 (PDT) In-Reply-To: References: <201707050350.53122.luke@dashjr.org> <00qcLaDJFDoC9D6644P_aLf7_n5B1pqCPj_c02QlqySsrJLsB6TZipXMD8L7l3lJcw5NoLP6dphCMruKJCIMkJUIDYbIw0iDd322vsNFmNw=@protonmail.ch> <201707050410.45217.luke@dashjr.org> From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Thu, 6 Jul 2017 19:20:47 +0200 Message-ID: To: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Height based vs block time based thresholds 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: Thu, 06 Jul 2017 17:20:50 -0000 I'm all for using height instead of time. That was my preference for bip9 all along, but my arguments at the time apparently weren't convincing. Regarding luke's proposal, the only advantage I see is that it would allow nodes that don't know a deployment that gets activated to issue a warning, like bip9 always does when an unknown deployment is locked in. But there's a simpler way to do that which doesn't require to add consensus rules as to what versionbits should be. I'm honestly not worried about it being "coersive" and I don't think it's inherently reckless (although used with short deployment times like bip148 it can be IMO). But it adds more complexity to the consensus rules, with something that could merely be "warning code". You can just use a special bit in versionbits for nodes to get the warning. My proposal doesn't guarantee that the warning will be signaled, for example, if the miner that mines the block right after lock in doesn't know about the deployment, he can't possibly know that he was supposed to signal the warning bit, even if he has the best intentions. Miners can also intentionally not signal it out of pure malice. But that's no worse than the current form, when deployments activated by final date instead of miner signaling never get a warning. Shaolinfry had more concerns with my proposed modification, but I think I answered all of them here: https://github.com/bitcoin/bitcoin/pull/10462#issuecomment-306266218 The implementation of the proposal is there too. I'm happy to reopen and rebase to simplify (#10464 was merged and there's at least 1 commit to squash). > It also enables deploying softforks as a MASF, and only upgrading them to= UASF on an as-needed basis. You can also do consensus.vDeployments[Consensus::DEPLOYMENT_MASF].bit =3D 0; consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nStartHeight =3D 500000; consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight =3D 51000= 0; consensus.vDeployments[Consensus::DEPLOYMENT_MASF].lockinontimeout =3D fals= e; and "if needed", simply add the following at any time (before the new nStartHeight, obviously): consensus.vDeployments[Consensus::DEPLOYMENT_UASF].bit =3D 0; consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nStartHeight =3D 510000; consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nTimeoutHeight =3D 51500= 0; consensus.vDeployments[Consensus::DEPLOYMENT_UASF].lockinontimeout =3D true= ; On Wed, Jul 5, 2017 at 9:44 PM, Hampus Sj=C3=B6berg via bitcoin-dev wrote: > From the PR change: > >> Miners must continue setting the bit in LOCKED_IN phase so uptake is >> visible and acknowledged. Blocks without the applicable bit set are inva= lid >> during this period > > Luke, it seems like the amendments to BIP8 make it drastically different = to > how it first was designed to work. > It now looks more akin to BIP148, which was AFAICT not how BIP8 was > originally intended to work. > Perhaps this should be made into its own BIP instead, or make it so it's > possible to decide how the LOCKED_IN state should work when designing the > softfork. > > Hampus > > 2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev > : >> >> It's not pointless: it's a wake-up call for miners asleep "at the wheel"= , >> to >> ensure they upgrade in time. Not having a mandatory signal turned out to >> be a >> serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a >> problem >> for BIP 149 as-is). Additionally, it makes the activation decisive and >> unambiguous: once the lock-in period is complete, there remains no >> question as >> to what the correct protocol rules are. >> >> It also enables deploying softforks as a MASF, and only upgrading them t= o >> UASF >> on an as-needed basis. >> >> Luke >> >> >> On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote: >> > Luke, >> > I previously explored an extra state to require signalling before >> > activation in an earlier draft of BIP8, but the overall impression I g= ot >> > was that gratuitous orphaning was undesirable, so I dropped it. I >> > understand the motivation behind it (to ensure miners are upgraded), b= ut >> > it's also rather pointless when miners can just fake signal. A properl= y >> > constructed soft fork is generally such that miners have to deliberate= ly >> > do something invalid - they cannot be tricked into it... and miners ca= n >> > always chose to do something invalid anyway. >> > >> > > -------- Original Message -------- >> > > From: luke@dashjr.org >> > > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry >> > > I"ve already opened a PR almost 2 weeks a= go >> > > to do this and fix the other issues BIP 9 has. >> > > https://github.com/bitcoin/bips/pull/550 >> > > It just needs your ACK to merge. >> > > >> > > On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrot= e: >> > >> Some people have criticized BIP9"s blocktime based thresholds argui= ng >> > >> they are confusing (the first retarget after threshold). It is also >> > >> vulnerable to miners fiddling with timestamps in a way that could >> > >> prevent or delay activation - for example by only advancing the blo= ck >> > >> timestamp by 1 second you would never meet the threshold (although >> > >> this >> > >> would come a the penalty of hiking the difficulty dramatically). On >> > >> the >> > >> other hand, the exact date of a height based thresholds is hard to >> > >> predict a long time in advance due to difficulty fluctuations. >> > >> However, >> > >> there is certainty at a given block height and it"s easy to monitor= . >> > >> If >> > >> there is sufficient interest, I would be happy to amend BIP8 to be >> > >> height based. I originally omitted height based thresholds in the >> > >> interests of simplicity of review - but now that the proposal has >> > >> been >> > >> widely reviewed it would be a trivial amendment. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >