Various changes to BIP9 #344

pull sipa wants to merge 3 commits into bitcoin:master from sipa:bip9work changing 2 files +108 −108

sipa commented at 3:15 AM on March 1, 2016: member
- Add start time
- Specify the state transitions less ambiguously.
- Add a state diagram.
Add start time 226bd097a9
Update former BIP references and consistency 737bf29de2
Rewrite state transition logic 8315dfd3fa
luke-jr referenced this in commit 976d5856b3 on Mar 1, 2016
luke-jr merged this on Mar 1, 2016
luke-jr closed this on Mar 1, 2016
sipa commented at 3:25 AM on March 1, 2016: member

@gmaxwell @rustyrussell @CodeShark @petertodd Feel free to comment here
sipa cross-referenced this on Mar 1, 2016 from issue Minimal BIP9 implementation by sipa
sdaftuar commented at 6:08 PM on March 1, 2016: member

@sipa I have a question about this sentence:

Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3) requirement already makes that impossible.

This statement seems incorrect: couldn't we just use 01 as the first two bits, which would satisfy all prior ISM rollouts while also leaving 30 bits available for parallel softfork deployment? Am I missing something?
sipa commented at 6:19 PM on March 1, 2016: member

Nice catch. The sentence dates from before the 001 prefix was introduced.
jtimon commented at 6:50 PM on March 1, 2016: contributor

Yeah, that was very confusing. On the other hand, from what I understand there's still only 29 bits available since the first bit (aka hardfork bit) is still invalid and the other zero in the prefix is reserved for future use.
jtimon commented at 6:55 PM on March 1, 2016: contributor

Also, I insist the threshold is per-chain while the start time, bit and time out are per-deployment. @sipa this is what you have implemented. I challenge you to implement a per-deployment threshold without completely breaking the warning check.

in bip-0009.mediawiki:None in 8315dfd3fa

  60 | +# '''DEFINED''' is the first state that each soft fork starts out as. The genesis block is by definition in this state for each deployment.
  61 | +# '''STARTED''' for blocks past the starttime.
  62 | +# '''LOCKED_IN''' for one retarget period after the first retarget period with STARTED blocks of which at least threshold have the associated bit set in nVersion.
  63 | +# '''ACTIVE''' for all blocks after the LOCKED_IN retarget period.
  64 | +# '''FAILED''' for one retarget period past the timeout time, if LOCKED_IN was not reached.
  65 | +# '''ABANDONED''' for all blocks after the FAILED retarget period.

jtimon commented at 6:58 PM on March 1, 2016:

why this additional state? isn't enough that it fails that it also has to be abandoned?

CodeShark commented at 10:38 PM on March 1, 2016:

I think having a retargeting period where the bit cannot be reused is a good idea. Having an extra state can force this.

CodeShark commented at 10:39 PM on March 1, 2016: contributor

@sipa I gave it a once over and I really like what you did.
FelixWeis commented at 1:01 AM on March 2, 2016: none

really like the proposal. Maybe just make it a little more clear how/if a bit becomes available again once it reached one of the final stages.

Contributors