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 18:53:20 +0100 [thread overview]
Message-ID: <CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com> (raw)
In-Reply-To: <87mvwqb132.fsf@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]
On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> '''States'''
> With every softfork proposal we associate a state BState, which begins
> at ''defined'', and can be ''locked-in'', ''activated'',
> or ''failed''. Transitions are considered after each
> retarget period.
>
I think the 75% rule should be maintained. It confirms that miners who are
setting the bit are actually creating blocks that meet the new rule (though
it doesn't check if they are enforcing it).
What is the reason for aligning the updated to the difficulty window?
*defined*
Miners set bit
If 75% of blocks of last 2016 have bit set, goto tentative
*tentative*
Miners set bit
Reject blocks that have bit set that don't follow new rule
If 95% of blocks of last 2016 have bit set, goto locked-in
*locked-in*
Point of no return
Miners still set bit
Reject blocks that have bit set that don't follow new rule
After 2016 blocks goto notice
*activated*
Miners don't set bit for at least 10080 blocks
Reject blocks that don't follow new rule
'''Failure: Timeout'''
> A soft fork proposal should include a ''timeout''.
>
I think counting in blocks is easier to be exact here.
If two bits were allocated per proposal, then miners could vote against
forks to recover the bits. If 25% of the miners vote against, then that
kills it.
In the rationale, it would be useful to discuss effects on SPV clients and
buggy miners.
SPV clients should be recommended to actually monitor the version field.
[-- Attachment #2: Type: text/html, Size: 2579 bytes --]
next prev parent reply other threads:[~2015-09-16 17:53 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 [this message]
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
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-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@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