Should revisit; I am not sure whether we have a long-term stable
URL for prebuilt past Elements releases, but we should be able
to just point test/get-previous-releases.py at that, and change
the set of versions (since we do not have 0.15, 0.19, etc), and
we're good to go.
Everyone is _not_ connected in this test, so on slow machines
where this check triggers (e.g. the CI boxes) the test incorrectly
fails. This was also a source of (very infrequent) spurious failures
during the rebase.
Includes a memory leak in the checkqueue unit test (but not in
the actual code). WE really need to switch our checkqueue to use
std::unique_pointer rather than bare pointers. But this would be
invasive enough that I want to do it in a followup PR.
Also pretty-much disable the validation_flush_cache unit test.
This is a stupid and irritating test which tries to unit-test
exact memory usage of std containers. It already has at least
one "remove wrong assumptions" update upstream and after many
tries I was unable to change all the magic numbers in a way
that'd consistently pass CI for Elements.
Also adds a couple ubsan suppressions about perfectly-legitimate
conversions of integer types.
It may be that we just need to recompute some numbers because our
block limits are different. But this test takes 20 minutes to
fail and it would take some time to understand what the expected
behavior is.
This fails on upstream commit messages which are incorrectly formatted
and there is obviously nothing we can do about this. Re-enable this
check after the rebase is merged.
Commit f471a3be00 currently has the text "scripted diff"
rather than "scripted-diff", which causes the scripted-diff linter to fail, saying
that it sees a script but not the magic words.
Changing the linter to detect "scripted diff" causes it to fail on this commit,
because the included script does not work. (For reference, the script is
r() { sed -i 's/vout must be positive/vout cannot be negative/g' $1 }
r $(git grep -l 'vout must be positive')
Bet you can't guess why bash rejects this without running it!)
We should remember to change this back.
Several conflicts in the C++ code related to the new `flags` parameter
to `CheckSignature` and the corresponding function being renamed upstream
to `CheckSignatureECDSA`.
Several conflicts in the test harness as Steven sorta pulled the new
upstream ECKey module into the Python code, and the actual upstream
code was slightly different. Also needed to update the feature_taproot
code to always use the non-RANGEPROOF sighash since dynafed is not
enabled in the Taproot test.
Also had to pull the `set_wif` method out of `ECKey` and inline it because
otherwise it triggers a "circular inclusion" error between script.py (which
would pull in `base58_to_bytes` from address.py) and address.py (which now
pulls in some taproot EC related stuff from script.py).
Noticed that #960 does not test the "sighash rangeproof flag set but no
witnesses" case.
