From: Rusty Russell <rusty@rustcorp•com.au>
To: "Bitcoin Dev" <bitcoin-dev@lists•linuxfoundation.org>
Cc: Pieter Wuille <pieter.wuille@gmail•com>
Subject: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.
Date: Wed, 30 Sep 2015 12:00:23 +0930 [thread overview]
Message-ID: <87zj04fxkw.fsf@rustcorp.com.au> (raw)
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;
next reply other threads:[~2015-09-30 2:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 2:30 Rusty Russell [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zj04fxkw.fsf@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox