Conversation
|
"Currently" seems confusing, as the retarget interval is not something that is easy to change. The interval for BIP9 however IS easy to change. |
|
@sipa What do you mean by the 'interval for BIP9'? Is this the amount of blocks that is needed for a proposed soft fork to go from 'DEFINED' to 'ACTIVE'/'FAILED'? |
|
The sampling interval. BIP9 specifies to sample at every retarget, which is
every 2016 blocks. However, the sampling interval van be changes to
something else, the retarget interval can't. So saying that the retarget
interval is 'currently' 2016 is confusing.
|
|
Interesting, perhaps we should add language around that in the BIP as well. It doesn't seem like that is said explicitly in the BIP right now. I'll write something up wrt to that later. I'll also remove the word 'currently'. |
|
Never mind, i'm not going to add language around the sampling interval. Assuming everyone is ok with my last change I'm not going to add any more commits. |
|
Luke-Jr notifications@github.com writes: Surprised retarget period needs definition. If you want to, I'd say These are tallied each retarget period. To: These are tallied each retarget period (2016 blocks). Cheers, |
|
@rustyrussell's suggestion looks fine |
Define the retarget period Update bip-0009.mediawiki Update bip-0009.mediawiki
|
@luke-jr @sipa i've changed it to what @rustyrussell suggested and rebased. Should be good to merge |
|
Weak NACK - this isn't really detailed enough to be an implementable spec by itself, as there's other details about retarget periods that you'd need to know to actually implement this. So with that in mind I'd rather just keep calling it a "retarget period" in the spirit of "the code is the spec; bips just describe intent" |
5 participants
Define the retarget period