Also move /test/README.md

So is it assumed that the parameters are global to the state? The design becomes a little bit more efficient in some regards if the parameter as given in the example is considered global to the run of the program vs living in the "config" object.

I like this task I can take a shot at it.

Yhis will require special privileges, so I'm not sure we want to bootcamp this.

This should be fixed now

This might be able to be configured through a Phabricator setting:

confirming same issue for me.

I'm not sure how you're supposed to check:

Are you saying that Part 1 should be a separate test, Part 2 should be a separate test, and etc...?

Can you explain this further? Do you just renaming variables and methods with txid or txhash in the name?

The general idea is to have something that works as follow:

I've added https://reviews.bitcoinabc.org/D1139 to be used for MTP activation... Since it's a trailing indicator ABC will likely activate after BU's activation by local system time.

Resolved by D1089

Is it OK to store timing.json in git (test/function/timing.json)?

Hmm, PushSig already has default SigHashType parameter (introduced in D932):

@jasonbcox, should I also try to remove the following functions from DstEncode.h:

At D1028

ok, on it.

Fixed the task title and descrition. It wasn't CChainParams directly, but rather a subcomponent of that, which is Consensus::Params. Look at calls to ContextualCheckBlock and it will be clear that the "params" parameter is redundant. Thanks for taking a look at this. :)

Checking ContextualCheckBlock at https://reviews.bitcoinabc.org/source/bitcoin-abc/browse/master/src/validation.cpp;2c81a03ad212b73ca7002ef9f9f891a025c1f6bd$3523

This flag should be added as part of the build as it is not a default on all the plateforms.

Right now, a lot of developers understand how to use Github. For a variety of reasons, we have chosen to use Phabricator, and will remain on Phabricator for the time being.