From: Gavin Andresen <gavinandresen@gmail•com>
To: Tom Harding <tomh@thinlink•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
Date: Wed, 23 Sep 2015 15:01:55 -0400 [thread overview]
Message-ID: <CABsx9T3pFAbtOv78uwaoToHWRXQGwmHA_h8KR89X2HLxiose5g@mail.gmail.com> (raw)
In-Reply-To: <5602F075.4000102@thinlink.com>
[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]
I say keep it simple.
If the 75% threshold is hit, then support suddenly drops off below 50%,
"meh" -- there will be a big ruckus, everybody will freak out, and miners
will refuse to build big blocks because they'll worry that they'll get
orphaned.
Adding more complexity for a case that ain't gonna happen (and isn't a
disaster if it does) is a mistake, in my humble opinion.
On Wed, Sep 23, 2015 at 2:33 PM, Tom Harding via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote:
>
>> '''Success: Activation Delay'''
>> 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.
>>
>>
> Rather than a simple one-period delay, should there be a one-period
> "burn-in" to show sustained support of the threshold? During this period,
> support must continuously remain above the threshold. Any lapse resets to
> inactivated state.
>
> With a simple delay, you can have the embarrassing situation where support
> falls off during the delay period and there is far below threshold support
> just moments prior to enforcement, but enforcement happens anyway.
>
> BIP 101 has this problem too.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 2551 bytes --]
next prev parent reply other threads:[~2015-09-23 19:01 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
2015-09-18 1:19 ` Rusty Russell
2015-09-23 18:33 ` Tom Harding
2015-09-23 19:01 ` Gavin Andresen [this message]
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=CABsx9T3pFAbtOv78uwaoToHWRXQGwmHA_h8KR89X2HLxiose5g@mail.gmail.com \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tomh@thinlink$(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