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 E5F39259 for ; Wed, 19 Aug 2015 09:34:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DDB64112 for ; Wed, 19 Aug 2015 09:34:55 +0000 (UTC) Received: by lbbpu9 with SMTP id pu9so120141894lbb.3 for ; Wed, 19 Aug 2015 02:34:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TE3gmKMS8TSuMErGCREcIJLJ40jjjFI2LhRb47t+Kpw=; b=Mpa85Nccw98R19Lwplj/UzbZRFxo23fcvHLC1X1+FsqdUkdjfwZDVZ2BjyVzfVWq0o tT4wdCYswD8mvRm7EYJiqFB2SBZnBY89o28gzXYKVeiT1GBmx95+6H14+cNaqBuyI9fb o3BpjzArsCPUQaqQeJviA//QtXGN1ZM+kmkzjxNDlZ6uCthiLWH1Or5s4Yc7lzSxyGe4 Tl60rzTuW8p55ASy8a+9bJVg/HrMUEjnsHOQvFUA84IqsHnPI30KgUFRDnPYRxjFLKDr 904824NUuagOldfbMC8ir3g0RqbN8YWE+5E2ZDmlqBBsNcH3/MB2VilGQFXMuh8CNZyn SEHw== X-Gm-Message-State: ALoCoQkUI884I2uzwd5UYPGH2CyTK1WbVYY1E/rvCXq+hCdnSxY47SCwRPAMeYOFoMnMoVvdTNGN MIME-Version: 1.0 X-Received: by 10.112.11.233 with SMTP id t9mr8755427lbb.104.1439976894286; Wed, 19 Aug 2015 02:34:54 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Wed, 19 Aug 2015 02:34:54 -0700 (PDT) In-Reply-To: References: <20150819055036.GA19595@muck> Date: Wed, 19 Aug 2015 11:34:54 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Mark Friedenbach Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev , Pieter Wuille Subject: Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 09:34:57 -0000 Seems like 3 is something we want to do no matter what and therefore is the "most future-proof" solution. I wonder if I can help with that (and I know there's more people that would be interested). Where's the current "non-full" nVersion bits implementation? Why implement a "non-full" version instead of going with the full implementation directly? On Wed, Aug 19, 2015 at 8:10 AM, Mark Friedenbach via bitcoin-dev wrote: > We can use nVersion & 0x8 to signal support, while keeping the consensus > rule as nVersion >= 4, right? That way we don't waste a bit after this all > clears up. > > On Aug 18, 2015 10:50 PM, "Peter Todd via bitcoin-dev" > wrote: >> >> Deployment of the proposed CLTV, CSV, etc. soft-forks has been recently >> complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners. Both >> mine blocks with nVersion=0x20000007, which would falsely trigger the >> previously suggested implementation using the IsSuperMajority() >> mechanism and nVersion=4 blocks. Additionally while the >> XT/Not-Bitcoin-XT software claims to support Wuille/Todd/Maxwell's >> nVersion soft-fork mechanism(3) a key component of it - fork >> deadlines(3) - is not implemented. >> >> >> XT/Not-Bitcoin-XT behavior >> -------------------------- >> >> Both implementations produce blocks with nVersion=0x20000007, >> or in binary: 0b001...111 >> >> Neither implementation supports a fork deadline; both Not-Bitcoin-XT and >> XT will produce blocks with those bits set indefinitely under any >> circumstance, with the proviso that while XT has a hashing power >> majority, blocks it produces might not be part of the Bitcoin blockchain >> after Jan 11th 2016. (though this can flap back and forth if reorgs >> happen) >> >> Curiously the BIP101 draft was changed(4) at the last minute from using >> the nVersion bits compliant 0x20000004 block nVersion, to using two more >> bits unnecessarily. The rational for doing this is unknown; the git >> commit message associated with the change suggested "compatibility >> concerns", but what the concerns actually were isn't specified. Equally >> even though implementing the fork deadline would be very each in the XT >> implementation, this was not done. (the XT codebase has had almost no >> peer review) >> >> >> Options for CLTV/CSV/etc. deployment >> ------------------------------------ >> >> 1) Plain IsSuperMajority() with nVersion=4 >> >> This option can be ruled out immediately due to the high risk of >> premature triggering, without genuine 95% miner support. >> >> >> 2) nVersion mask, with IsSuperMajority() >> >> In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would >> be masked away, prior to applying standard IsSuperMajority() logic: >> >> block.nVersion & ~0x20000007 >> >> This means that CLTV/CSV/etc. miners running Bitcoin Core would create >> blocks with nVersion=8, 0b1000. From the perspective of the >> CLTV/CSV/etc. IsSuperMajority() test, XT/Not-Bitcoin-XT miners would be >> advertising blocks that do not trigger the soft-fork. >> >> For the perpose of soft-fork warnings, the highest known version can >> remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT blocks >> as well as a future nVersion bits implementation. Equally, >> XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an >> unknown bit set. >> >> When nVersion bits is implemented by the Bitcoin protocol, the plan of >> setting the high bits to 0b001 still works. The three lowest bits will >> be unusable for some time, but will be eventually recoverable as >> XT/Not-Bitcoin-XT mining ceases. >> >> Equally, further IsSuperMajority() softforks can be accomplished with >> the same masking technique. >> >> This option does complicate the XT-coin protocol implementation in the >> future. But that's their problem, and anyway, the maintainers >> (Hearn/Andresen) has strenuously argued(5) against the use of soft-forks >> and/or appear to be in favor of a more centralized mandatory update >> schedule.(6) >> >> >> 3) Full nVersion bits implementation >> >> The most complex option would be to deploy via full nVersion bits >> implementation using flag bit #4 to trigger the fork. Compliant miners >> would advertise 0x20000008 initially, followed by 0x20000000 once the >> fork had triggered. The lowest three bits would be unusable for forks >> for some time, although they could be eventually recovered as >> XT/Not-Bitcoin-XT mining ceases. >> >> The main disadvantage of this option is high initial complexity - the >> reason why IsSuperMajority() was suggested for CLTV/CSV in the first >> place. That said, much of the code required has been implemented in XT >> for the BIP101 hard-fork logic, although as mentioned above, the code >> has had very little peer review. >> >> >> References >> ---------- >> >> 1) https://github.com/bitcoinxt/bitcoinxt >> >> 2) https://github.com/xtbit/notbitcoinxt >> >> 3) "Version bits proposal", >> Pieter Wuille, May 26th 2015, Bitcoin-development mailing list, >> >> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008282.html, >> https://gist.github.com/sipa/bf69659f43e763540550 >> >> 4) >> https://github.com/bitcoin/bips/commit/3248c9f67bd7fcd1d05b8db7c5c56e4788deebfe >> >> 5) "On consensus and forks - What is the difference between a hard and >> soft fork?", >> Mike Hearn, Aug 12th 2015, >> https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7 >> >> 6) 2013 San Jose Bitcoin conference developer round-table >> >> -- >> 'peter'[:-1]@petertodd.org >> 00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d >> >> _______________________________________________ >> 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 >