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 20474A7F for ; Thu, 6 Jul 2017 17:41:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f53.google.com (mail-pg0-f53.google.com [74.125.83.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 277DE178 for ; Thu, 6 Jul 2017 17:41:56 +0000 (UTC) Received: by mail-pg0-f53.google.com with SMTP id u62so4307182pgb.3 for ; Thu, 06 Jul 2017 10:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Tjlz/w/EgVvfccGECqmPp8qPcQ4FOXjU8sJKLgEtEkM=; b=OcYgJ+BD1s5+UD3yFDoR4JQ+bDnXWa3TdBml7OPZGzUIAbpMCU1EPwwI93aFEuD/p7 av3yjYCppt8q64xCJ9zcfOxMLY24+glnLjvXigSn09zc0fXT8OcGmWs8GALwraIlYRNL 3MuZyplwAujM6+QrwoHyqKttpHA9Pk2NEu8Ye4N9gSrkRmL/xsHq+6jDY5hMIEZ0VZxo 8UFOglTBiSDQvgMsxHRn63iuIbSr5jePfNAp8p8m/BcjGvl9ajvi0AJb4kY/RBJSaNVn Q0r9sRkw50N+5O68evXkKJKIGx1JIsSVNN17Vqj6Xtmeg4xGCiqtsyVrxIZFVs/319XH prOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Tjlz/w/EgVvfccGECqmPp8qPcQ4FOXjU8sJKLgEtEkM=; b=fmFKlzpQadd9WJdrNFclMzSt0X91e3vNC7ViXv8FWEIFCUl3Iv++1K13p3MksFC7in Tpp1ot/jmbahJkmDZEVM1mw1tny/W/AyAhiLGgFLR40CKXHtN4sosbrzxupAQn6ZOEmm smOdPohIqc2x/ZBIIrIjIQWHbQdt/7BPsiNJdMw8UvtBKmnOpHWmOg0TT9mQsXzbpIdT b1tlbOXvixi0/S38X+lFRmOyAFW0s65J64qtRrxkaG6ZFnzT23MtWsUSX5hMUT3kH90w J2DVY5FMH9YrFckiCKytx6L67/yZ73O1jshCif8j7AQan370I08HjElQZoNEz7IDJjw6 IZKg== X-Gm-Message-State: AIVw111MfDfzPMEJ+rV9+qQ9RqwQmB9ezD3R63LheylJtG/TM+16oJ5g 8/SKt93ery5hIVdvdcYprg== X-Received: by 10.99.104.10 with SMTP id d10mr25815007pgc.186.1499362915383; Thu, 06 Jul 2017 10:41:55 -0700 (PDT) Received: from ?IPv6:2600:380:8070:6d94:786a:6c9a:2dec:2bf1? ([2600:380:8070:6d94:786a:6c9a:2dec:2bf1]) by smtp.gmail.com with ESMTPSA id q67sm1553049pfi.81.2017.07.06.10.41.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 10:41:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Thu, 6 Jul 2017 10:41:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3248E9A6-F729-4EC2-85F7-E18FD9CA15F8@voskuil.org> References: <201707050350.53122.luke@dashjr.org> <00qcLaDJFDoC9D6644P_aLf7_n5B1pqCPj_c02QlqySsrJLsB6TZipXMD8L7l3lJcw5NoLP6dphCMruKJCIMkJUIDYbIw0iDd322vsNFmNw=@protonmail.ch> <201707050410.45217.luke@dashjr.org> To: =?utf-8?Q?Jorge_Tim=C3=B3n?= X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 06 Jul 2017 17:54:20 +0000 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:41:57 -0000 Just as an implementation consideration, time basis creates complexity. Ther= e are no other reasons to index by time, but many to index by height. The ti= me-based activation window of BIP9 forces nodes to either index by time or s= can the chain. e > On Jul 6, 2017, at 10:20 AM, Jorge Tim=C3=B3n via bitcoin-dev wrote: >=20 > 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. >=20 > 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. >=20 > 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". >=20 > 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. >=20 > Shaolinfry had more concerns with my proposed modification, but I > think I answered all of them here: >=20 > https://github.com/bitcoin/bitcoin/pull/10462#issuecomment-306266218 >=20 > 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). >=20 >> It also enables deploying softforks as a MASF, and only upgrading them to= UASF > on an as-needed basis. >=20 > You can also do >=20 > consensus.vDeployments[Consensus::DEPLOYMENT_MASF].bit =3D 0; > consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nStartHeight =3D 500000= ; > consensus.vDeployments[Consensus::DEPLOYMENT_MASF].nTimeoutHeight =3D 5100= 00; > consensus.vDeployments[Consensus::DEPLOYMENT_MASF].lockinontimeout =3D fal= se; >=20 > and "if needed", simply add the following at any time (before the new > nStartHeight, obviously): >=20 >=20 > consensus.vDeployments[Consensus::DEPLOYMENT_UASF].bit =3D 0; > consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nStartHeight =3D 510000= ; > consensus.vDeployments[Consensus::DEPLOYMENT_UASF].nTimeoutHeight =3D 5150= 00; > consensus.vDeployments[Consensus::DEPLOYMENT_UASF].lockinontimeout =3D tru= e; >=20 >=20 > On Wed, Jul 5, 2017 at 9:44 PM, Hampus Sj=C3=B6berg via bitcoin-dev > wrote: >> =46rom the PR change: >>=20 >>> 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 >>=20 >> Luke, it seems like the amendments to BIP8 make it drastically different t= o >> 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. >>=20 >> Hampus >>=20 >> 2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev >> : >>>=20 >>> 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. >>>=20 >>> It also enables deploying softforks as a MASF, and only upgrading them t= o >>> UASF >>> on an as-needed basis. >>>=20 >>> Luke >>>=20 >>>=20 >>>> 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 go= t >>>> was that gratuitous orphaning was undesirable, so I dropped it. I >>>> understand the motivation behind it (to ensure miners are upgraded), bu= t >>>> it's also rather pointless when miners can just fake signal. A properly= >>>> constructed soft fork is generally such that miners have to deliberatel= y >>>> do something invalid - they cannot be tricked into it... and miners can= >>>> always chose to do something invalid anyway. >>>>=20 >>>>> -------- Original Message -------- >>>>> From: luke@dashjr.org >>>>> To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry >>>>> I"ve already opened a PR almost 2 weeks ago= >>>>> 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. >>>>>=20 >>>>>> On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote= : >>>>>> Some people have criticized BIP9"s blocktime based thresholds arguing= >>>>>> 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 block= >>>>>> 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 >>=20 >>=20 >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev