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 3C52C83D for ; Wed, 19 Aug 2015 10:20:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A090510D for ; Wed, 19 Aug 2015 10:20:37 +0000 (UTC) Received: by ykdt205 with SMTP id t205so232379ykd.1 for ; Wed, 19 Aug 2015 03:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pBDlypZdVmnWeg1ul6kV4ufz9LdmZeiUO3DNSKPTAZM=; b=qnM9V58IXXVk0gqNT8pS9eT1UJS23BoHCe7N41XtGXiKce6xOh214qlp7idIuizITg lYQ0hHi22TGSw3nrWE6nKYGomKFQaV7E0PXsLqY36g8cgEzyJUYqgRubJiMurwWWxlYV qVy2pGEmYGgYNoYNj+SjDR3qjxIwuW8OmQRfSESdVOqfne/B56hHXH47LzjcFLSb0JeZ FQfILc36lrdUvQ7GQRoAUwTdLar6T8Vjhw0r7FWuOyaSQpZej13sKe/6HSbIp9ucIjaC Wf1P37GHSP2PqnM7vvfywtmygEJt7aEJPpdlPCRrpveJEY9ObcuRSKkdT6W7dvkYoOn7 nwLA== X-Received: by 10.170.97.9 with SMTP id o9mr12590748yka.84.1439979636901; Wed, 19 Aug 2015 03:20:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.37.73 with HTTP; Wed, 19 Aug 2015 03:20:17 -0700 (PDT) In-Reply-To: References: <20150819055036.GA19595@muck> From: Btc Drak Date: Wed, 19 Aug 2015 11:20:17 +0100 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=001a113b4874bdcc34051da762a9 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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 , 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 10:20:38 -0000 --001a113b4874bdcc34051da762a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 19, 2015 at 10:34 AM, Jorge Tim=C3=B3n < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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? There is a simple answer to this, convenience: versionbits has not been implemented yet, and I believe the BIP is still in review stage. As it seems likely the remaining locktime pull requests will be ready by or before the next major release, we need a deployment method if versionbits is not ready (which is unlikely because no-one appears to be working on it at the moment). Pieter indicated he is OK with another IsSuperMajority() rollout in the interim. Personally, I dont think we should let perfection be the enemy of progress here because at the end of the day, the deployment method is less important than the actual featureset being proposed. That said, the features in the next soft fork proposal are all related and best deployed as one featureset softfork, but moving forward, versionbits seems essential to be able to roll out multiple features in parallel without waiting for activation and enforcement each time. --001a113b4874bdcc34051da762a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 19, 2015 at 10:34 AM, Jorge Tim=C3=B3n <bitcoi= n-dev@lists.linuxfoundation.org> wrote:
Seems like 3 is something we want to do no matter what and th= erefore
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?<= br> Why implement a "non-full" version instead of going with the full=
implementation directly?

There is a simple = answer to this, convenience: versionbits has not been implemented yet, and = I believe the BIP is still in review stage. As it seems likely the remainin= g locktime pull requests will be ready by or before the next major release,= we need a deployment method if versionbits is not ready (which is unlikely= because no-one appears to be working on it at the moment). Pieter indicate= d he is OK with another IsSuperMajority() rollout in the interim. Personall= y, I dont think we should let perfection be the enemy of progress here beca= use at the end of the day, the deployment method is less important than the= actual featureset being proposed.

That said, the = features in the next soft fork proposal are all related and best deployed a= s one featureset softfork, but moving forward, versionbits seems essential = to be able to roll out multiple features in parallel without waiting for ac= tivation and enforcement each time.





--001a113b4874bdcc34051da762a9--