Gavin Andresen [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-23 📝 Original message:I say keep it simple. If ...

📅 Original date posted:2015-09-23
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



--
--
Gavin Andresen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150923/c8d94f63/attachment.html>;