Showing "not_applicable" if BIP9 timeout is 0 #8209

pull jl2012 wants to merge 1 commits into bitcoin:master from jl2012:patch-13 changing 1 files +10 −1

jl2012 commented at 5:49 PM on June 16, 2016: contributor

getblockchaininfo will show a BIP9 proposal as "not_applicable" (instead of "failed") if the timeout is 0. A timeout before the genesis block timestamp guaruntees that a softfork must not be activated in any circumstances. A timeout of 0 should be used when we want to merge a softfork proposal without defining its deployment schedule
laanwj added the label RPC/REST/ZMQ on Jun 17, 2016
instagibbs commented at 5:36 PM on June 17, 2016: member

This new logic seems "out there" to the reader. You may want to document the reasoning for this check.
Showing "not_applicable" if BIP9 timeout is 0 c1322bee11
jl2012 force-pushed on Jun 17, 2016
jl2012 commented at 6:35 PM on June 17, 2016: contributor

Comments added

in src/rpc/blockchain.cpp:None in c1322bee11

 905 | @@ -897,7 +906,7 @@ UniValue getblockchaininfo(const UniValue& params, bool fHelp)
 906 |              "  ],\n"
 907 |              "  \"bip9_softforks\": {          (object) status of BIP9 softforks in progress\n"
 908 |              "     \"xxxx\" : {                (string) name of the softfork\n"
 909 | -            "        \"status\": \"xxxx\",    (string) one of \"defined\", \"started\", \"lockedin\", \"active\", \"failed\"\n"
 910 | +            "        \"status\": \"xxxx\",    (string) one of \"defined\", \"started\", \"locked_in\", \"active\", \"failed\", \"not_applicable\"\n"

paveljanik commented at 1:52 PM on June 18, 2016:

lockedin: Good catch!

paveljanik commented at 2:01 PM on June 18, 2016: contributor

So when such a softfork is merged in, what is its state (according to BIP9)? Should we merge in the source code and keep consensus.vDeployments filled in in such cases? Isn't it better to comment it out instead? Or change BIP9 to reflect this new not-yet-DEFINED state?
sipa commented at 2:07 PM on June 18, 2016: member

I think we should just hide deployments whose end time is 0. For all intents and purposes, the software behaves as if the deployment didn't exist at all.
jl2012 commented at 4:58 PM on June 24, 2016: contributor

replaced by #8258
jl2012 closed this on Jun 24, 2016
MarcoFalke locked this on Sep 8, 2021

Contributors

Labels

Linked (view graph)

#8258 RPC: Hide softfork if timeout is 0