* [bitcoin-dev] Versionbits BIP (009) minor revision proposal.
@ 2015-09-30 2:30 Rusty Russell
2015-09-30 2:57 ` Gregory Maxwell
0 siblings, 1 reply; 7+ messages in thread
From: Rusty Russell @ 2015-09-30 2:30 UTC (permalink / raw)
To: Bitcoin Dev; +Cc: Pieter Wuille
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.
Cheers,
Rusty.
diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index c17ca15..b160810 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -37,14 +37,15 @@ retarget period.
Software which supports the change should begin by setting B in all blocks
mined until it is resolved.
- if (BState == defined) {
+ if (BState != activated && BState != failed) {
SetBInBlock();
}
'''Success: Lock-in Threshold'''
If bit B is set in 1916 (1512 on testnet) or
more of the 2016 blocks within a retarget period, it is considered
-''locked-in''. Miners should stop setting bit B.
+''locked-in''. Miners should continue setting bit B, so uptake is
+visible.
if (NextBlockHeight % 2016 == 0) {
if (BState == defined && Previous2016BlocksCountB() >= 1916) {
@@ -57,7 +58,7 @@ more of the 2016 blocks within a retarget period, it is considered
The consensus rules related to ''locked-in'' soft fork will be enforced in
the second retarget period; ie. there is a one retarget period in
which the remaining 5% can upgrade. At the that activation block and
-after, the bit B may be reused for a different soft fork.
+after, miners should stop setting bit B, which may be reused for a different soft fork.
if (BState == locked-in && NextBlockHeight == BActiveHeight) {
BState = activated;
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal. 2015-09-30 2:30 [bitcoin-dev] Versionbits BIP (009) minor revision proposal Rusty Russell @ 2015-09-30 2:57 ` Gregory Maxwell 2015-09-30 4:46 ` Eric Lombrozo 2015-10-01 0:26 ` Rusty Russell 0 siblings, 2 replies; 7+ messages in thread From: Gregory Maxwell @ 2015-09-30 2:57 UTC (permalink / raw) To: Rusty Russell; +Cc: Bitcoin Dev, Pieter Wuille On Wed, Sep 30, 2015 at 2:30 AM, Rusty Russell <rusty@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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal. 2015-09-30 2:57 ` Gregory Maxwell @ 2015-09-30 4:46 ` Eric Lombrozo 2015-09-30 5:09 ` Eric Lombrozo 2015-10-01 0:26 ` Rusty Russell 1 sibling, 1 reply; 7+ messages in thread From: Eric Lombrozo @ 2015-09-30 4:46 UTC (permalink / raw) To: Gregory Maxwell, Rusty Russell; +Cc: Bitcoin Dev, Pieter Wuille 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@gmail•com> To: "Rusty Russell" <rusty@rustcorp•com.au> Cc: "Bitcoin Dev" <bitcoin-dev@lists•linuxfoundation.org>; "Peter Todd" <pete@petertodd•org>; "Pieter Wuille" <pieter.wuille@gmail•com>; "Eric 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> >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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal. 2015-09-30 4:46 ` Eric Lombrozo @ 2015-09-30 5:09 ` Eric Lombrozo 0 siblings, 0 replies; 7+ messages in thread From: Eric Lombrozo @ 2015-09-30 5:09 UTC (permalink / raw) To: Gregory Maxwell, Rusty Russell; +Cc: Bitcoin Dev, Pieter Wuille >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. > I should add that hard forks do provide us with a means to determine whether or not miners are enforcing the new rules...but generally speaking they risk far greater disruption if anything fails to go as planned. Between the risk of clients accepting an occasional invalid "confirmation" or two and the risk of a total network partition, the former seems far less serious. I believe the concerns regarding old clients can be remedied to a very large extent by means of a good awareness campaign. - Eric ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal. 2015-09-30 2:57 ` Gregory Maxwell 2015-09-30 4:46 ` Eric Lombrozo @ 2015-10-01 0:26 ` Rusty Russell 2015-10-01 2:54 ` Eric Lombrozo 2015-10-02 1:22 ` Rusty Russell 1 sibling, 2 replies; 7+ messages in thread From: Rusty Russell @ 2015-10-01 0:26 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev, Pieter Wuille Gregory Maxwell <gmaxwell@gmail•com> writes: > 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. Introducing this later would trigger warnings on older clients, who would consider the bit to represent a new soft fork :( So if we want this middle ground, we should sew it in now, though it adds a other state. Simplest is to have miners keep setting the bit for another 2016 blocks. If we want to later, we can make this a consensus rule. "Bitcoin is hard, let's go shopping!" "With Bitcoin!" "..." Rusty. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal. 2015-10-01 0:26 ` Rusty Russell @ 2015-10-01 2:54 ` Eric Lombrozo 2015-10-02 1:22 ` Rusty Russell 1 sibling, 0 replies; 7+ messages in thread From: Eric Lombrozo @ 2015-10-01 2:54 UTC (permalink / raw) To: Rusty Russell, Gregory Maxwell; +Cc: Bitcoin Dev, Pieter Wuille [-- Attachment #1: Type: text/plain, Size: 2369 bytes --] I can go along with making it optional but recommended for the first deployment and making it mandatory later on. It would be purely informational for now...but it will give us valuable data. As has been said before, most of these BIP deployments will likely be accompanied by recommended default settings for miners. Assuming the BIP itself is not very controversial, the gravest dangers come not so much from miners (or pool operators, more accurately) deliberately choosing to lie...but more from either shortcuts taken in implementations and/or bugs. Collecting additional data will help spot faulty implementations and allow us to intervene. Eventually, I imagine a much more sophisticated signaling mechanism where endusers can be given highly informative messages regarding changes and we can have a way of directing people to resources where they can learn more about the new features. - Eric On September 30, 2015 5:26:51 PM PDT, Rusty Russell <rusty@rustcorp•com.au> wrote: >Gregory Maxwell <gmaxwell@gmail•com> writes: >> 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. > >Introducing this later would trigger warnings on older clients, who >would consider the bit to represent a new soft fork :( > >So if we want this middle ground, we should sew it in now, though it >adds a other state. Simplest is to have miners keep setting the bit >for >another 2016 blocks. If we want to later, we can make this a consensus >rule. > >"Bitcoin is hard, let's go shopping!" "With Bitcoin!" "..." >Rusty. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. [-- Attachment #2: Type: text/html, Size: 2879 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal. 2015-10-01 0:26 ` Rusty Russell 2015-10-01 2:54 ` Eric Lombrozo @ 2015-10-02 1:22 ` Rusty Russell 1 sibling, 0 replies; 7+ messages in thread From: Rusty Russell @ 2015-10-02 1:22 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev, Pieter Wuille Rusty Russell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> writes: > Gregory Maxwell <gmaxwell@gmail•com> writes: >> 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. > > Introducing this later would trigger warnings on older clients, who > would consider the bit to represent a new soft fork :( Actually, this isn't a decisive argument, since we can use the current mechanism to upgrade versionbits, or as Eric says, tack it on to an existing soft fork. So, I think I'm back where I started. We leave this for now. There was no nak on the "keep setting bit until activation" proposal, so I'm opening a PullReq for that now: https://github.com/bitcoin/bips/pull/209 Cheers, Rusty. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-10-02 1:23 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-09-30 2:30 [bitcoin-dev] Versionbits BIP (009) minor revision proposal Rusty Russell 2015-09-30 2:57 ` Gregory Maxwell 2015-09-30 4:46 ` Eric Lombrozo 2015-09-30 5:09 ` Eric Lombrozo 2015-10-01 0:26 ` Rusty Russell 2015-10-01 2:54 ` Eric Lombrozo 2015-10-02 1:22 ` Rusty Russell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox