f2a0050f31 primitives: do not de/serialize asset issuance in bitcoin mode (Andrew Poelstra)
9c1de4d85f ci: give more memory to a couple Cirrus jobs (Andrew Poelstra)
40c09f637c rpc: fix error message accidentally changed in 5e62edc (Andrew Poelstra)
adbd9f163a qt: fix PSBT/PSET change from 4839db857d (Andrew Poelstra)
057237bd02 qt: fix double-scoping of enum introduced in c3b6bbb (Andrew Poelstra)
5819f25975 bitcoin-tx: add ASSET to the help text of some option (Andrew Poelstra)
1f3cfb451a chainparamsbase: fix bool-vs-enum mistake in 9c3480fea9 (Andrew Poelstra)
2573747447 fix test code duplication from 3a0de44d90 (Andrew Poelstra)
0045cafd75 rpc/mining: restore code erroneously dropped in 0e2c963dbf (Andrew Poelstra)
39112e1eaa correct copy/paste error in error message (Andrew Poelstra)
Pull request description:
ACKs for top commit:
stevenroose:
utACK f2a0050
Tree-SHA512: 5ce831ef24e51e76b93cd4d8e345a382dbd716e38c99565a7c2f25b5eeb8bac1e36c623491c5763ceb7b47444024b5821a878942df150bb01b33eeae33f292b1
This was causing build failures on win64, and since we (currently) do
not expose any dynafed or PAK stuff in libelementsconsensus, there is
no reason to be trying to link these.
Also rename libbitcoin_consensus to libelements_consensus more
consistently in src/Makefile.am. I'm not sure this was causing any
problems but it did make it harder to follow what autotools is
thinking.
Bitcoin allocates 32M for signature caching by default, split
between a signature cache and a script validity cache (see
Core #10192). Since 0.14 we have added an additional 32M for
rangeproof caching *and* an additional 32M for surjectionproof
caching.
These cache entries cost a bit over 32 bytes, so these are room
for a million entries....or 4Gb of rangeproofs and 300M of
surjection proofs.
Presumably we did not intend to triple memory usage relative to
Core to deal with some champagne problem in which our mempool is
overfilled ten times with pure rangeproofs. So put the total
default cache size back to 32M. This should have no performance
hit under realistic circumstances and should reduce CI OOM failures.
On my system we now use 50M rather than 110M during the fedpeg
test; we still use 18M that Core does not by having three additional
global secp contexts (one in blind.cpp, one in pegins.cpp, one in
confidential_validation.cpp) but we can settle that in a future
commit.
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.
Includes removing some variables from qt/intro.cpp that've been
unused since #13216 and ought to have been removed in the 0.17
rebase, but our linters were not so agressive then. Similarly
fix the BITCOIN_PID_FILE, whose value was incorrectly changed
in the 0.18 rebase.
This is broken in multiple ways, does not exist in 0.14, appears in an
unreviewed mega-PR "porting" from a version of liquid-qt that I cannot
track down, and apparently has caused a fair bit of follow-on trouble
with icon integration.
Just put the icons in the repo like upstream does.
The committed icons were built using the Makefile prior to this
commit, starting from ./share/pixmaps/nsis-wizard.svg and
./src/qt/res/src/bitcoin.svg. They should be recreated manually
if they need to be changed in the future.
These "pass" locally but in CI they download pre-signed transactions
from https://github.com/bitcoin-core/qa-assets/ which we need to
fork and recreate.
Essentially these files are the output of the Taproot functional
test (which passes), so I am not too worried about actual failures
here. But we should wait until after the Taproot sighash is finalized
to recreate these assets.
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.
