After discussion in #7164 I think this is better.
Max tip age was introduced in #5987 to make it possible to run testnet-in-a-box. But associating this behavior with the testnet chain is wrong conceptually, as it is not needed in normal usage. Should aim to make testnet test the software as-is.
Replace it with a (debug) option -maxtipage, which can be specified only in the specific case.
After discussion in #7164 I think this is better.
Max tip age was introduced in #5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.
Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.
ACK
concept ACK, utACK 64360f1
utACK 64360f1
994 | @@ -994,6 +995,8 @@ bool AppInit2(boost::thread_group& threadGroup, CScheduler& scheduler) 995 | if (GetBoolArg("-peerbloomfilters", true)) 996 | nLocalServices |= NODE_BLOOM; 997 | 998 | + nMaxTipAge = GetArg("-maxtipage", DEFAULT_MAX_TIP_AGE);
minor nit, maybe
nMaxTipAge = GetArg("-maxtipage", nMaxTipAge);
to not use DEFAULT_MAX_TIP_AGE twice (nMaxTipAge is already initialized to DEFAULT_MAX_TIP_AGE in main.cpp, this seems a little bit redundant)? Anyway, minor minor minor style nit. Feel more than free to ignore.
I've always tried to avoid using the current value as default anywhere for GetArg. Specifying DEFAULT_MAX_TIP_AGE is more clear when reading the code, and when at some point argument parsing is refactored it's nice to have the defaults on hand without having to 'reason back' about the value.
It's fine, as said it was a very minor nit. Maybe we can remove the redundant initialization in main.cpp? Whatever we do, I'm fine, as long as we try to be consistent among all the globals (which imo should be in globals/server.o of something of the short instead of main chainparams, etc [globals/common.o could take the globals in unit.o and basechainparams, for example]; but one step a a time...).
utACK https://github.com/laanwj/bitcoin/commit/64360f13044125fbb3cdcbe2e5e8f2bfb82a8b27 There's definitely way too many things in chainparams that shouldn't be there. Ping @luke-jr
Concept ACK. Do any RPC tests need this set for them?
Extended tests seem to pass.
Concept ACK. Do any RPC tests need this set for them?
I don't think this is used by any RPC tests. This was introduced because of testnet-in-a-box, which we don't use for RPC tests. @MarcoFalke's test seems to confirm this.