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

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

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

activated

Miners don't set bit for at least 10080 blocks
Reject blocks that don't follow new rule

'''Failure: Timeout'''
A soft fork proposal should include a ''timeout''.

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

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.

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.