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.
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.
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
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.
4e28753f60 feestimator: encapsulate estimation file logic (Antoine Poinsot)
e8ea6ad9c1 init: don't create a CBlockPolicyEstimator if we don't relay transactions (Antoine Poinsot)
86ff2cf202 Remove the remaining fee estimation globals (Antoine Poinsot)
03bfeee957 interface: remove unused estimateSmartFee method from node (Antoine Poinsot)
Pull request description:
If the `blocksonly` mode is turned on after running with transaction
relay enabled for a while, the fee estimation will serve outdated data
to both the internal wallet and to external applications that might be
feerate-sensitive and make use of `estimatesmartfee` (for example a
Lightning Network node).
This has already caused issues (for example https://github.com/bitcoin/bitcoin/issues/16840 (C-lightning), or https://github.com/lightningnetwork/lnd/issues/2562 (LND)) and it seems prudent to fail rather than to give inaccurate values.
This fixes#16840, and closes#16890 which tried to fix the symptoms (RPC) but not the cause as mentioned by sdaftuar :
> If this is a substantial problem, then I would think we should take action to protect our own wallet users as well (rather than hide the results of what our fee estimation would do!).
ACKs for top commit:
MarcoFalke:
re-ACK 4e28753f60👋
jnewbery:
utACK 4e28753f60
Tree-SHA512: c869cf03b86d8194002970bbc84662dae76874967949b9be0d9a4511a1eabcb1627c38aca3154da9dcece1a4c49ec02bd4f9fcca2ec310986e07904559e63ba8
This moves the CBlockPolicyEstimator to the NodeContext, which get rids
of two globals and allows us to conditionally create the
CBlockPolicyEstimator (and to remove a circular dep).
Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
Changes API for AcceptToMemoryPool to no longer check maximum fee; we remove
this check from interfaces::CChain::testPeginClaimAcceptance. This is fine,
the check never should have been there (this method's job is to notice double
claim attempts and provide a more helpful message to the user; other mempool
failures should be caught later in the `claimrawpegin` logic when we call
`pwallet->commitTransaction` which actually subits to the mempool). It was
only checking fees because the API made it easier to do so than to not.
This commit adds signet support, which is a little bit silly/redundant for us :)
Was a surprisingly easy merge to handle, and hopefully in future Core is more
mindful of signed blocks when they are changing code architecture.
I had to change a couple lines of src/signet.cpp to add blank assets to the
CTxOuts and to find transaction input scriptWitnesses. No need to add any
other tx witness data (and the CAsset()s that I did add to make things compile
won't be used..) because signet will always have g_con_elementsmode off.
Added a method testPeginClaimAcceptance to interfaces::CChain. It is not clear
to me that this is meaningfully different from the existing method broadcastTransaction
(with the `relay` flag set to false so it doesn't actually broadcast), except
that this method returns the TxValidationState, which we display to the user
in the RPC error. Worth revisiting this.
Another nonobvious change was replacing a block of mempool-searching logic
in wallet/rpcwallet.cpp with the single line `pwallet->chain().findCoins(coins)`.
This I stole from the current state of upstream #17211, our favorite in-progress
PR from which the original logic came.
