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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.
Precedence: list

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.