path: root/ff/c2825c1a4ece763d6115073042c128a7b976ce

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EB6001626
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 30 Sep 2015 04:46:38 +0000 (UTC)
Received: by pacex6 with SMTP id ex6so27713317pac.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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" <elombrozo@gmail.com>
To: "Gregory Maxwell" <gmaxwell@gmail.com>, "Rusty Russell"
	<rusty@rustcorp.com.au>
Date: Wed, 30 Sep 2015 04:46:25 +0000
Message-Id: <ema32ec38f-3384-48e2-9ab3-6064e4c73bde@platinum>
In-Reply-To: <CAAS2fgTXP0j6K3sxp=HL9j2-xvO8y_VnpG+iZw9kaxmnxZQjSw@mail.gmail.com>
Reply-To: "Eric Lombrozo" <elombrozo@gmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>,
	Pieter Wuille <pieter.wuille@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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" <gmaxwell@gmail.com>
To: "Rusty Russell" <rusty@rustcorp.com.au>
Cc: "Bitcoin Dev" <bitcoin-dev@lists.linuxfoundation.org>; "Peter Todd"=20
<pete@petertodd.org>; "Pieter Wuille" <pieter.wuille@gmail.com>; "Eric=20
Lombrozo" <elombrozo@gmail.com>
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 <rusty@rustcorp.com.au>=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.