For enforcing new restrictions on your own blocks (thus at the policy level, not consensus) you don't need to wait for 75%. You can do it from the start (this way all miners setting the bit will enforce the new restrictions.
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.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev