From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
Date: Wed, 16 Sep 2015 21:30:27 +0100 [thread overview]
Message-ID: <CAE-z3OW6BKHfx=wS9AYqb4+Ems6xM+SDqBKgGbNkXfPwuPqn8A@mail.gmail.com> (raw)
In-Reply-To: <87r3lyjewl.fsf@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]
On Wed, Sep 16, 2015 at 9:19 PM, Rusty Russell <rusty@rustcorp•com.au>
wrote:
> I couldn't see a use for it, since partial enforcement of a soft fork is
> pretty useless.
>
It isn't useful for actually using the feature, but some miners might set
the bit but not actually create blocks that comply with the new rule.
This would cause their blocks to be orphaned until they fixed it.
OK, *that* variant makes perfect sense, and is no more complex, AFAICT.
>
> So, there's two weeks to detect bad implementations, then you everyone
> stops setting the bit, for later reuse by another BIP.
>
It could be more than two weeks if the support stays between 80% and 90%
for a while.
75%+ checks that blocks with the bit set follow the rule.
95%+ enters lock-in and has the same rules as 75%+, but is irreversible at
that point.
> You need a timeout: an ancient (non-mining, thus undetectable) node
> should never fork itself off the network because someone reused a failed
> BIP bit.
>
I meant if the 2nd bit was part of the BIP. One of the 2 bits is "FOR" and
the other is "AGAINST". If against hits 25%, then it is deemed a failure.
The 2nd bit wouldn't be used normally. This means that proposals can be
killed quickly if they are obviously going to fail.
[-- Attachment #2: Type: text/html, Size: 2103 bytes --]
next prev parent reply other threads:[~2015-09-16 20:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-13 18:56 Rusty Russell
2015-09-16 15:53 ` Btc Drak
2015-09-16 17:53 ` Tier Nolan
2015-09-16 20:19 ` Rusty Russell
2015-09-16 20:27 ` Jorge Timón
2015-09-16 20:32 ` Tier Nolan
2015-09-16 20:38 ` Jorge Timón
2015-09-16 20:48 ` Tier Nolan
2015-09-16 20:54 ` Jorge Timón
2015-09-16 20:57 ` Tier Nolan
2015-09-16 21:03 ` Jorge Timón
2015-09-16 22:52 ` Eric Lombrozo
2015-09-17 10:38 ` Tier Nolan
2015-09-17 13:59 ` Jorge Timón
2015-09-17 21:57 ` Rusty Russell
2015-09-17 22:00 ` Rusty Russell
2015-09-19 5:04 ` Jorge Timón
2015-09-20 3:56 ` Rusty Russell
2015-09-21 8:24 ` Jorge Timón
2015-09-21 10:34 ` Rusty Russell
2015-09-16 20:30 ` Tier Nolan [this message]
2015-09-18 1:19 ` Rusty Russell
2015-09-23 18:33 ` Tom Harding
2015-09-23 19:01 ` Gavin Andresen
2015-09-30 2:05 ` Rusty Russell
2015-09-30 23:41 ` Tom Harding
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='CAE-z3OW6BKHfx=wS9AYqb4+Ems6xM+SDqBKgGbNkXfPwuPqn8A@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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