The following signet startup messages are printed to the debug log immediately on node startup for all chains. This behavior occurs on master as a side effect after the merge of #20014. This PR removes the first message and moves the signet derived magic logging to init.cpp.
$ ./src/bitcoind
2020-09-30T14:25:15Z Using default signet network
2020-09-30T14:25:15Z Signet derived magic (message start): 0a03cf40
2020-09-30T14:25:15Z Bitcoin Core version v0.20.99.0 ...
Seems odd for a constructor to log anyway. I'd say to remove them or move them elsewhere
Makes sense, but I didn't move them because they are related to the values being set, and because the first message interrelates with the other -signetchallenge messages and value settings. Pinging @kallewoof for thoughts.
Concept ACK
Agree with MarcoFalke regarding removing them from the ctor.
Concept ACK.
Concept and utACK
Removing is fine, but they're useful esp for custom signets since you need the magic for external software.
The magic is logged unconditionally in the constructor. If needed, it can be logged unconditionally in the startup-sequence, e.g. init.cpp
and move signet network magic logging from chainparams.cpp to init.cpp
Updated proposal: removed the first message and moved the signet network magic message to init.cpp.
utACK 6fccad7f711df330e461c1fab3f758d078345ed5
ACK 6fccad7f711df330e461c1fab3f758d078345ed5
Maybe also add testing for not appearing signet messages in the log if not on signet?
ACK 6fccad7f711df330e461c1fab3f758d078345ed5
Maybe also add testing for not appearing signet messages in the log if not on signet?
TBH was tempted but thought even the one added test might be overkill.
Maybe also add testing for not appearing signet messages in the log if not on signet?
I just tested this manually, and it seems unlikely and low-risk to regress