public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp•com.au>
To: 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: Thu, 17 Sep 2015 05:49:22 +0930	[thread overview]
Message-ID: <87r3lyjewl.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com>

Tier Nolan via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
writes:
> 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).

I couldn't see a use for it, since partial enforcement of a soft fork is
pretty useless.

Your point about checking that miners are actually doing it is true,
though all stuff being forked in in future will be nonstandard AFAICT.

I bias towards simplicity for this.

> What is the reason for aligning the updated to the difficulty window?

Miners already have that date in their calendar, so prefer to anchor to
that.

> *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

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.

> I think counting in blocks is easier to be exact here.

Easier for code, but harder for BIP authors.

> 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.

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.

> 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.

SPV clients don't experience a security change when a soft fork occurs?
They're already trusting miners.

Greg pointed out that soft forks tend to get accompanied by block forks
across activation, but SPV clients should *definitely* be taking those
into account whenever they happen, right?

Thanks!
Rusty.


  reply	other threads:[~2015-09-16 20:20 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 [this message]
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=87r3lyjewl.fsf@rustcorp.com.au \
    --to=rusty@rustcorp$(echo .)com.au \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=tier.nolan@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