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.
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.
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.
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.
7aaf01e02f Test duration of fedpeg validity in dynafed test (Steven Roose)
Pull request description:
I noticed this scenario was not really tested in the test
Tree-SHA512: 05b112b8d2859b1ea718b473c80b6bf0e75fed4f0441cbfafa673b44c2c4d4dad7e932568983ecba6c124baeddbc350193a5c0a0079696a6a67cee1cadb1a586
2f40d80b01 Further revisions in response to comments (Glenn Willen)
7207226d9c Update elements branching proposal based on chat with apoelstra (Glenn Willen)
115f622a6e Proposals/ideas for elements tracking of upstream bitcoin git branches (Glenn Willen)
Pull request description:
This goes along with #954 (which is a tool for assisting the review process) and #935 (which was created using approximately this process.)
It's already had some internal review inside Blockstream, and probably should just get merged now, as a description of the process we're currently trying out; then we can have followup PRs once we know how we feel about it / if we want to revise it.
@stevenroose ?
Tree-SHA512: 7ec57d5bf9dba191565b6403d64638ff9bb43bc4e3ab0c54c85ffcc384ff9602e01f0af4c6208a22d0987d3c24fc1b1f8a57e9f48686cfa03cde10072923b1e1
77349c16a5 Update the copyright year to 2021 (Philippe McLean)
Pull request description:
Tree-SHA512: edb5bab1bc9a06aea52eb71bc889a51da75ef213a1ae7c6e0cd1fe56a51cc5213b7a730a223db76f1d9ad3de9ec9c5a4c755b8312510b876469966736e708ddb
a8a1a933d Make it clear that the CRangeCheck is not called on explicit values (Steven Roose)
Pull request description:
That is enforced by the `VerifyAmounts` method for regular transactions
and by the `VerifyIssuanceAmounts` method for issuance values.
Tree-SHA512: 69064ca21dbe3a574f38ba8ea9a13cc2d4b6d0ac2b306fad59ff6fa92e63e08c8f4607da82c31731dcf91044eb47c8d79ced2ff49c7c0843343f438eb8bac943
14a42a018 Add two missing dynafed fields to getblockchaininfo (Steven Roose)
fe0372933 dynafed: Support changing mainnet dynafed activation (Steven Roose)
ce7a93d93 dynafed: Only verify proposed parameters if they differ from current (Steven Roose)
Pull request description:
- support blocksigners specifying their own activation to make coordination a bit more flexible
- don't force fedpeg script to change in order to change the block signing script
Tree-SHA512: 8dd66440261f910b083f7ed461e1930c9380350e3648f6aca44726c39dcca3bb7e62c36d36ae56c2717827fbaee2b9046c6ce0b05441c1d8d1b54f3c284bc4d7
b888f4227 tests: Add test feature_sighash_rangeproof.py (Steven Roose)
691040a63 Add SIGHASH_RANGEPROOF support (Steven Roose)
236f0b176 tests: Replace CECKey with new ECKey impl from Bitcoin master (Steven Roose)
Pull request description:
Add a new sighash flag that includes the rangeproof information in the signature. This avoids certain kinds of malleability in PSBT scenarios.
Tree-SHA512: 60b52ca88a64d81a38f5c70bae810e477f69e6402553b24fa22e59b9a8491c077168576187e7da88e525591933907ea77e937242af6d248908bfedbb8532bb33
Somehow the CECKey impl is really broken if you want to set
a raw private key. Core master already has a new impl so I just
took that one and replaces the usages. This will probably be equivalent
with what would be rebased in at a later stage.
This allows the initial relaxed restriction on non-segwit fedpeg
programs to be extended as long as the fedpeg program is not changed
while the block signing parameters can be changed.
