public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
Date: Thu, 17 Sep 2015 11:38:29 +0100	[thread overview]
Message-ID: <CAE-z3OWu7HgHh=8nAZMfJaekL03HHXvHrkRBho=aBAoRtHR9Eg@mail.gmail.com> (raw)
In-Reply-To: <CDB1F26E-FE26-44F3-9A86-CDAE33A51B8B@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

On Wed, Sep 16, 2015 at 11:52 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:

> The exact numbers (95% vs. 75% etc) don't need to be completely specified
> to start working on an implementation. What really matters for now is
> defining the states and trigger mechanisms. I'd rather we not argue over
> the optimal values for supermajority requirement at this point.
>

The discussion was about what each state means, not the thresholds
exactly.  I agree that can be set later.

On Wed, Sep 16, 2015 at 10:03 PM, Jorge Timón <jtimon@jtimon.cc> wrote:

> I understand your proposal, but I don't see what it accomplishes compared
to applying the new rule from the start (in your own blocks)

> and wait for 95% for consensus activation (which is my preference and
it's much simpler to implement).
> What are the disadvantages of my approach? What are the advantages of
yours?
I agree that miners should apply the rule from the start in their own
blocks.


*defined*
Miners set bit
Miners apply rule to their own blocks
If 75% of blocks of last 2016 have bit set, goto tentative


*tentative*
Miners set bit
Miners apply rule to their own blocks
Miners enforce rule in blocks with bit set (reject invalid blocks)
If 95% of blocks of last 2016 have bit set, goto locked-in


*locked-in*

Point of no return
Miners set bit
Miners apply rule to their own blocks
Miners enforce rule in blocks with bit set (reject invalid blocks)
After 2016 blocks goto activated


*activated*

Miners don't set bit
Reject any block that has the bit set for 10080 blocks (10 diff periods)
Reject blocks that don't follow new rule

The advantage of enforcing the rule when 75% is reached (but only for
blocks with the bit set) is that miners get early notification that they
have implemented the rule incorrectly.    They might produce blocks that
they think are fine, but which aren't.

[-- Attachment #2: Type: text/html, Size: 2605 bytes --]

  reply	other threads:[~2015-09-17 10:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-13 18:56 [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay 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 [this message]
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-z3OWu7HgHh=8nAZMfJaekL03HHXvHrkRBho=aBAoRtHR9Eg@mail.gmail.com' \
    --to=tier.nolan@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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