just rebase

Should help with failures like this https://build.bitcoinabc.org/viewLog.html?buildId=28271&buildTypeId=BitcoinABC_Master_BitcoinAbcMasterAsan

bugfix: D5177 too

OK so why the orphaning handling is weird.... (this is exercising a weird edge case):

good-getdata and bad-getdata near end of test_framework.log: https://build.bitcoinabc.org/repository/download/BitcoinABC_Master_BitcoinAbcMasterAsan/28193:id/test-output.tar.gz%21/bitcoin_test_runner_20200205_183212/p2p_compactblocks_542/test_framework.log

2020-02-06T02:36:05.841000Z TestFramework.mininode (DEBUG): Received message from 127.0.0.1:15337: msg_getdata(inv=[CInv(type=Block hash=7fdb3ff134fc96bf6b2b88e6c102a2ba214c40c4f4652a3599561b7622fd03b5)])
2020-02-06T02:36:05.842000Z TestFramework.mininode (DEBUG): Received message from 127.0.0.1:15337: msg_getdata(inv=[CInv(type=TX hash=6683ac8f07e73c074b211a2d372fe40000a8946d1945280f683cf20731e8380a), CInv(type=TX hash=bdf21b88966bbbbc4d243ac054519f7ce4de6b4b08ae7a905b08b3ff900740ec), CInv(type=TX hash=7ecb1213fa09ee5ebc348317601ce4d0f0ce88d16498f0a2500f4de0adca0df3), CInv(type=TX hash=dd74d819470a1f05788568a7762fa4a362798ad670ee880b632c78a9f5694799), CInv(type=TX hash=e76a9b0803ccbe34ace219f127fed6d7b63ef9561332a4565bf0114c50c74eed)])

In D2544#59209, @jasonbcox wrote:

@dagurval points out, maybe we want to go straight for https://github.com/bitcoin/bitcoin/pull/14670 ... sounds like this exits uncleanly in some cases?

Considering this and the importance of the 0.19 release, I'd prefer to get https://reviews.bitcoinabc.org/T537 ready to land shortly after landing this diff.
Although the risk doesn't seem that high, I don't like the idea of increased flakiness impacting our ability to react to fixing issues with the initial May upgrade release.

Should fix the spurious p2p_invalid_tx failure here: https://build.bitcoinabc.org/viewLog.html?buildId=28193&buildTypeId=BitcoinABC_Master_BitcoinAbcMasterAsan&tab=buildResultsDiv

reviewers: see end of summary

In D5169#124866, @teamcity wrote:

Build Bitcoin-ABC / Diffs / Diff Testing started.

I don't have windows but it should help to fix this problem: https://build.bitcoinabc.org/viewLog.html?buildId=28175&buildTypeId=BitcoinABC_Master_BitcoinAbcMasterAsan&tab=buildResultsDiv

we don't have self.sync_blocks yet

Theres's a backport for this: D5168 . I could have sworn I looked for backports on this, but apparently I missed that.

In D5029#124801, @deadalnix wrote:

While there is nothing wrong with that patch per se, it would be better to get the sigcheck nailed before landing this.

Yeah I get the same kind of timings and as you say, jumping branches gets to be a headache... I caved in finally and turned off the option locally.

(No joke about the speedup with sigops off... we're talking about logged ConnectBlock times going from 85 ms to 9 ms. And yes the test runs overall about 2x faster...)

updated to use a script flag instead.

support boost <= 1.58 which lack the BOOST_TEST_CONTEXT macro
(no context messages)

(apparently this requires boost 1.59 and our minversion is 1.58)

reduce braceyness

Yeah the specific boolean-based thing is going to be reworked. For the most part I just want to get review on which things are being deactivated (have I missed any), and the content of the deactivation tests.

update, various changes

Looks like a C++20 feature. https://en.cppreference.com/w/cpp/language/aggregate_initialization

I've also noted an issue in Core: https://github.com/bitcoin/bitcoin/issues/18065 , plus a few more details (the fix I used here is really a bandaid and does not fully solve the logical problem at hand).

Was discussing this with Fabien a fair bit.

also deactivate P2SH sigops limit; added a test for all of this

If this rearrangement is not desired, an alternative is to do the following:

1. pass a flag to CTxMemPoolEntry that disables use of sigops count when calculating virtual size (so that virtual size computations would not be used for sigchecks), and,
2. allow CTxMemPoolEntry to have its sigops count updated after creation. This would be done just before the insertion into mempool with addUnchecked ... obviously such an update shouldn't occur once it's in mempool.

speaking of palindromes, happy 20200202 https://www.youtube.com/watch?v=4fE_sXZjxng

use int

just rebase