Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-30 📝 Original message:Good points, Greg. The way ...
📅 Original date posted:2015-09-30
📝 Original message:Good points, Greg.
The way I see it, this mechanism isn't really about "voting" - it's
about deployment of fairly uncontroversial changes with the minimum
amount of negative disruption. If we have reason to believe a particular
BIP stands little chance of hitting the 95% mark relatively quickly,
it's probably better not to deploy it...so this mechanism is most useful
for adding fairly uncontroversial features provided as default settings
in product releases - and measuring adoption as best we can before
activating these features.
The current controversies around things like CLTV, CSV, etc... don't
seem to revolve around these features themselves - there seems to be
near-unanimous agreement that these features are good (and most
disagreements regarding functionality are over quite minor nits,
really). Instead the controversies are much more likely to be around
deployment strategies.
While I would like to get some form of explicit acknowledgment from
miners that a new rule is in effect, the truth of the matter is we still
lack a means to determine whether or not miners are actually enforcing
these rules...unless someone happens to mine a block that breaks the new
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
and building consensus (that should take place BEFORE we assign bits).
This is a deployment mechanism for fairly uncontroversial changes.
Either a BIP is relatively quickly adopted with overwhelming
support...or else perhaps it's best to wait until it has sufficient
support before attempting deployment (or perhaps not deploy it at all) -
and ultimately we want these transitions to run as smoothly as possible.
As long as the BIPs are relatively uncontroversial, miners will most
likely continue to choose to cooperate in the interest of the health of
the network (and will use recommended default settings). Once clients
have better support for this, perhaps we can do more sophisticated
signaling.
- Eric
------ Original Message ------
From: "Gregory Maxwell" <gmaxwell at gmail.com>
To: "Rusty Russell" <rusty at rustcorp.com.au>
Cc: "Bitcoin Dev" <bitcoin-dev at lists.linuxfoundation.org>; "Peter Todd"
<pete at petertodd.org>; "Pieter Wuille" <pieter.wuille at gmail.com>; "Eric
Lombrozo" <elombrozo at 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 at rustcorp.com.au>
>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
>>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
>>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.
📝 Original message:Good points, Greg.
The way I see it, this mechanism isn't really about "voting" - it's
about deployment of fairly uncontroversial changes with the minimum
amount of negative disruption. If we have reason to believe a particular
BIP stands little chance of hitting the 95% mark relatively quickly,
it's probably better not to deploy it...so this mechanism is most useful
for adding fairly uncontroversial features provided as default settings
in product releases - and measuring adoption as best we can before
activating these features.
The current controversies around things like CLTV, CSV, etc... don't
seem to revolve around these features themselves - there seems to be
near-unanimous agreement that these features are good (and most
disagreements regarding functionality are over quite minor nits,
really). Instead the controversies are much more likely to be around
deployment strategies.
While I would like to get some form of explicit acknowledgment from
miners that a new rule is in effect, the truth of the matter is we still
lack a means to determine whether or not miners are actually enforcing
these rules...unless someone happens to mine a block that breaks the new
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
and building consensus (that should take place BEFORE we assign bits).
This is a deployment mechanism for fairly uncontroversial changes.
Either a BIP is relatively quickly adopted with overwhelming
support...or else perhaps it's best to wait until it has sufficient
support before attempting deployment (or perhaps not deploy it at all) -
and ultimately we want these transitions to run as smoothly as possible.
As long as the BIPs are relatively uncontroversial, miners will most
likely continue to choose to cooperate in the interest of the health of
the network (and will use recommended default settings). Once clients
have better support for this, perhaps we can do more sophisticated
signaling.
- Eric
------ Original Message ------
From: "Gregory Maxwell" <gmaxwell at gmail.com>
To: "Rusty Russell" <rusty at rustcorp.com.au>
Cc: "Bitcoin Dev" <bitcoin-dev at lists.linuxfoundation.org>; "Peter Todd"
<pete at petertodd.org>; "Pieter Wuille" <pieter.wuille at gmail.com>; "Eric
Lombrozo" <elombrozo at 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 at rustcorp.com.au>
>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
>>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
>>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.