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 D29FB83D for ; Wed, 19 Aug 2015 10:32:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B8A3310D for ; Wed, 19 Aug 2015 10:31:59 +0000 (UTC) Received: by obbwr7 with SMTP id wr7so399513obb.2 for ; Wed, 19 Aug 2015 03:31:59 -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 :content-transfer-encoding; bh=GV9FIinTE5GWLXhYZQMZcCo8Fh3QnnMIPOuW0sqceGY=; b=GJ6wtOUZUEyd8KlVsFm6B6/ZvHGIkGkZS7cnanoOE+9IRNkhLkMqoTYWAG9a1OW/RA HLOdZ5WWHUzahODIs3FbwD4l7WbiCxfelSwQmm5m2vjGguRhnmOTh36I6WflxK8VcTbR l7SLOH6adyjo1HKnsqV69iK2JVO3ASC8cwib3p1KT2Hk6+sP1vP1wixjqfi4LwD0jy8U eN7UuAVvkWzKRhZfcZL6ff5RH0fLBHrKQZPe7u5khDc5ZCC+aBuYL4sVaut0Bgnp+o+I E6XvByilqjFvzv77QmP2OpsrIlF+iXZ+IRUA6qeCPCfVK7j2/y3WBhU+a17IrkDcG/Yk ZYLg== X-Gm-Message-State: ALoCoQmG3NooBrfSYHZc/ihp27jsx6Ytdhr6dLgP3oP7yzXGdXTWcEL7PsXy6o6+p4IQX/nxNiZ/ MIME-Version: 1.0 X-Received: by 10.60.70.104 with SMTP id l8mr9940452oeu.37.1439980319028; Wed, 19 Aug 2015 03:31:59 -0700 (PDT) Received: by 10.202.71.85 with HTTP; Wed, 19 Aug 2015 03:31:58 -0700 (PDT) In-Reply-To: References: <20150819055036.GA19595@muck> Date: Wed, 19 Aug 2015 12:31:58 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Btc Drak Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 10:32:01 -0000 I don't think just using version=3D4 for cltv and friends would be a problem if it wasn't for the XT/nonXT issue. On Wed, Aug 19, 2015 at 12:20 PM, Btc Drak wrote: > On Wed, Aug 19, 2015 at 10:34 AM, Jorge Tim=C3=B3n > 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 se= ems > likely the remaining locktime pull requests will be ready by or before th= e > next major release, we need a deployment method if versionbits is not rea= dy > (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 ene= my > 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 an= d > best deployed as one featureset softfork, but moving forward, versionbits > seems essential to be able to roll out multiple features in parallel with= out > waiting for activation and enforcement each time. > > > > >