Conversation
sipa
commented
Mar 1, 2016
sipa
commented
- Add start time
- Specify the state transitions less ambiguously.
- Add a state diagram.
|
@gmaxwell @rustyrussell @CodeShark @petertodd Feel free to comment here |
|
@sipa I have a question about this sentence:
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? |
|
Nice catch. The sentence dates from before the 001 prefix was introduced.
|
|
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. |
|
Also, I insist the threshold is per-chain while the start time, bit and time out are per-deployment. |
| # '''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. | ||
| # '''ACTIVE''' for all blocks after the LOCKED_IN retarget period. | ||
| # '''FAILED''' for one retarget period past the timeout time, if LOCKED_IN was not reached. | ||
| # '''ABANDONED''' for all blocks after the FAILED retarget period. |
There was a problem hiding this comment.
why this additional state? isn't enough that it fails that it also has to be abandoned?
There was a problem hiding this comment.
I think having a retargeting period where the bit cannot be reused is a good idea. Having an extra state can force this.
|
@sipa I gave it a once over and I really like what you did. |
|
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. |
6 participants
