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 EB6001626 for ; Wed, 30 Sep 2015 04:46:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F107C8E for ; Wed, 30 Sep 2015 04:46:38 +0000 (UTC) Received: by pacex6 with SMTP id ex6so27713317pac.0 for ; Tue, 29 Sep 2015 21:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version:content-type:content-transfer-encoding; bh=crb6yUmuhrkCNoBxrLXIw63EIzuIO16YuNRsY1z6wqA=; b=mBr+t6WCWaNrQm9i+CYEKTMFVRMXZM4YFTyD7a94Viw/6euYhGtTKl/TFtSS5zakEJ HLM05U4OQLy+PikXze1hOr61xTyEkLYqpdv7G5Wm3rEwTe4vHnPmBlHT3mjdj0hpbSOl CL/v83v7q6pnhN49DyORlxCizHemdGgVjTK0lPec2HqO3NhggdHd0A6ukBczxaEdHLyM IJ/ANpR89VD4xk/RR/mNImPraNQI/fMs3Oo0/Bmdk54cxoO15+UOLX2ionK8WYgEbNTV iVKu2c5GLa0KHmXxHhPfiICeU3rmjMrNPR7veH3lxTDZOkZ92ISCvlrUvwDWcAZHy38N i5og== X-Received: by 10.68.192.9 with SMTP id hc9mr2291961pbc.57.1443588398711; Tue, 29 Sep 2015 21:46:38 -0700 (PDT) Received: from [192.168.1.108] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id ej3sm28648859pbd.13.2015.09.29.21.46.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 29 Sep 2015 21:46:38 -0700 (PDT) From: "Eric Lombrozo" To: "Gregory Maxwell" , "Rusty Russell" Date: Wed, 30 Sep 2015 04:46:25 +0000 Message-Id: In-Reply-To: Reply-To: "Eric Lombrozo" User-Agent: eM_Client/6.0.23181.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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] Versionbits BIP (009) minor revision proposal. 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, 30 Sep 2015 04:46:40 -0000 Good points, Greg. The way I see it, this mechanism isn't really about "voting" - it's=20 about deployment of fairly uncontroversial changes with the minimum=20 amount of negative disruption. If we have reason to believe a particular= =20 BIP stands little chance of hitting the 95% mark relatively quickly,=20 it's probably better not to deploy it...so this mechanism is most useful= =20 for adding fairly uncontroversial features provided as default settings=20 in product releases - and measuring adoption as best we can before=20 activating these features. The current controversies around things like CLTV, CSV, etc... don't=20 seem to revolve around these features themselves - there seems to be=20 near-unanimous agreement that these features are good (and most=20 disagreements regarding functionality are over quite minor nits,=20 really). Instead the controversies are much more likely to be around=20 deployment strategies. While I would like to get some form of explicit acknowledgment from=20 miners that a new rule is in effect, the truth of the matter is we still= =20 lack a means to determine whether or not miners are actually enforcing=20 these rules...unless someone happens to mine a block that breaks the new= =20 rule. This is a bit frustrating...but that's just how it is. To sum up, Version Bits is not a mechanism for vetting proposed changes=20 and building consensus (that should take place BEFORE we assign bits).=20 This is a deployment mechanism for fairly uncontroversial changes.=20 Either a BIP is relatively quickly adopted with overwhelming=20 support...or else perhaps it's best to wait until it has sufficient=20 support before attempting deployment (or perhaps not deploy it at all) -= =20 and ultimately we want these transitions to run as smoothly as possible.= =20 As long as the BIPs are relatively uncontroversial, miners will most=20 likely continue to choose to cooperate in the interest of the health of=20 the network (and will use recommended default settings). Once clients=20 have better support for this, perhaps we can do more sophisticated=20 signaling. - Eric ------ Original Message ------ From: "Gregory Maxwell" To: "Rusty Russell" Cc: "Bitcoin Dev" ; "Peter Todd"=20 ; "Pieter Wuille" ; "Eric=20 Lombrozo" Sent: 9/29/2015 7:57:52 PM Subject: Re: Versionbits BIP (009) minor revision proposal. >On Wed, Sep 30, 2015 at 2:30 AM, Rusty Russell =20 >wrote: >> Hi all, >> >> Pieter and Eric pointed out that the current BIP has miners >> turning off the bit as soon as it's locked in (75% testnet / 95% >> mainnet). It's better for them to keep setting the bit until=20 >>activation >> (2016 blocks later), so network adoption is visible. >> >> I'm not proposing another suggestion, though I note it for future: >> miners keep setting the bit for another 2016 blocks after activation, >> and have a consensus rule that rejects blocks without the bit. That >> would "force" upgrades on those last miners. I feel we should see=20 >>how >> this works first. > > >Actually getting rid of the immediate bit forcing was something I >considered to be an advantage of versionbits over prior work. > >Consider, where possible we carve soft fork features out from >non-standard behavior. Why do we do this? Primarily so that >non-upgraded miners are not mining invalid transactions which >immediately cause short lived forks once the soft-fork activates. >(Secondarily to protect wallets from unconfirmed TX that won't ever >confirm). > >The version forcing, however, guarantees existence of the same forks >that the usage of non-standard prevented! > >I can, however, argue it the other way (and probably have in the >past): The bit is easily checked by thin clients, so thin clients >could use it to reject potentially ill-fated blocks from non-upgraded >miners post switch (which otherwise they couldn't reject without >inspecting the whole thing). This is an improvement over not forcing >the bit, and it's why I was previously in favor of the way the >versions were enforced. But, experience has played out other ways, >and thin clients have not done anything useful with the version >numbers. > >A middle ground might be to require setting the bit for a period of >time after rule enforcing begins, but don't enforce the bit, just >enforce validity of the block under new rules. Thus a thin client >could treat these blocks with increased skepticism.