c318211ddd walletdb: fix last client version update (furszy)
bda8ebe608 wallet: don't read db every time that a new WalletBatch is created (furszy)
Pull request description:
Found it while was working on #25297.
We are performing a db read operation every time that a new `WalletBatch` is created, inside the constructor, just to check if the client version field is inside the db or not.
As the client version field does not change in the entire db lifecycle, this operation can be done only once: The first time that the db is accessed/opened and the client version value can be cached.
ACKs for top commit:
achow101:
ACK c318211ddd
w0xlt:
reACK c318211ddd
Tree-SHA512: 7fb780c656e169e8eb21e7212242494a647f6506d6da2cca828703713d440d29c82bec9e7d2c410f37b49361226ccd80846d3eeb8168383d0c2a11d85d73bee2
50ba6697f3 remove unused functions (Ayush Sharma)
eec23dad1e test: remove wallet dependency from feature_nulldummy.py (Ayush Sharma)
Pull request description:
This PR enables one of the non-wallet functional tests (`feature_nulldummy.py`) to be run even with the Bitcoin Core wallet disabled.
Commit 1: removes wallet dependency and `test_runner.py` is edited to make sure the test only runs once.
Commit 2: the functions `create_transaction()` and `create_raw_transaction()` in `blocktools.py` are no longer needed and hence removed.
ACKs for top commit:
kouloumos:
re-ACK 50ba6697f3, all comments have been addressed.
Tree-SHA512: 3bc3d2766e53dba3d56a03f2c476442608ac693f51d84f4632a22a2cf169bc02c10bf92b676f7d57acb4f0ad86f307d37ab63f936b44b3585ee3c9d08cd0335f
Since TaprootBuilder has assertions for the depth and leaf versions, the
PSBT decoder should check these values before calling
TaprootBuilder::Add so that the assertions are not triggered on
malformed taproot trees.
e866f0d066 [functional test] submitrawpackage RPC (glozow)
fa076515b0 [rpc] add new submitpackage RPC (glozow)
Pull request description:
It would be nice for LN/wallet/app devs to test out package policy, package RBF, etc., but the only interface to do so right now is through unit tests. This PR adds a `-regtest` only RPC interface so people can test by submitting raw transaction data. It is regtest-only, as it would be unsafe/confusing to create an actual mainnet interface while package relay doesn't exist.
Note that the functional tests are there to ensure the RPC interface is working properly; they aren't for testing policy itself. See src/test/txpackage_tests.cpp.
ACKs for top commit:
t-bast:
Tested ACK against eclair e866f0d066
ariard:
Code Review ACK e866f0d0
instagibbs:
code review ACK e866f0d066
Tree-SHA512: 824a26b10d2240e0fd85e5dd25bf499ee3dd9ba8ef4f522533998fcf767ddded9f001f7a005fe3ab07ec95e696448484e26599803e6034ed2733125c8c376c84
475aae846e test: pass `datacarriersize` option for tests using large outputs (instead of `acceptnonstdtxn`) (Sebastian Falbesoner)
b1ba3ed155 test: let `gen_return_txouts` create a single large OP_RETURN output (Sebastian Falbesoner)
f319287d81 test: assert serialized txouts size of `gen_return_txouts` helper (Sebastian Falbesoner)
Pull request description:
By specifying the `datacarriersize` option instead of the more generic `acceptnonstdtxn` for functional tests, we can be more specific about what part of the transaction is non-standard and can be sure that all other aspects follow the standard policy. Transactions with more than one OP_RETURN output are [never considered standard](749b80b29e/src/policy/policy.cpp (L149-L153)), i.e. we have to change the `gen_return_txouts` helper to create only a single output in order to get rid of the `acceptnonstdxtn` option. Note that on master there is currently no test using the `datacarriersize` parameter, so this PR indirectly also increases the test coverage.
The change affects the tests `mempool_limit.py`, `mining_prioritisetransaction.py` (call `gen_return_txouts` directly) and `feature_maxuploadtarget.py` (calls `gen_return_txouts` indirectly via the `mine_large_block(...)` helper).
Top commit has no ACKs.
Tree-SHA512: c17f032e00d28f5e5880a4d378773fbc8b1995ea9c377f237598d412628fe117f497a44ebdfa8af8cd8a3b1e3127e0cf7692efbf5c833c713764a71a85301f23
d22bd543cc test: passing a non-positive integer value to `-peertimeout` should throw an error (brunoerg)
Pull request description:
This PR adds test coverage for #25506, since #25505 gets closed.
ACKs for top commit:
kristapsk:
ACK d22bd543cc
w0xlt:
ACK d22bd543cc
1440000bytes:
ACK d22bd543cc
Tree-SHA512: 89c8a097606cb52569d816cc2227baac832df70e381d07c4a12aeb024c500d334c8102218fc6519eebb3819159d8308119d7253d9192a6bebe13b8e738b286b9
rpc_signrawtransaction.py is split into rpc_signrawtransactionwithkey.py and wallet_signrawtransactionwithwallet.py.
rpc_signrawtransactionwithkey.py can be run with the wallet disabled.
Follow-up to #617. This applies translator strings to the
reset options confirmation dialog and also refactors the way we pass the
strings to the dialog in order to allow the comments to be applied.
Because the strings were being concatenated, we can not apply translator
comments to all of the relevant strings. What we want to do instead is
have a variable in which the translatable strings are appended to using
the QString append function. This satisfies the Qt translator engine and
the comments are then properly applied within the `extracomment` field
in the translation file.
28a28a0c5b Squashed 'src/minisketch/' changes from 7eeb778fef..47f0a2d26f (fanquake)
Pull request description:
Contains:
* https://github.com/sipa/minisketch/pull/65
* https://github.com/sipa/minisketch/pull/66
Required for #25493.
ACKs for top commit:
achow101:
ACK dc375e5cce
hebasto:
ACK dc375e5cce, I have reviewed the code and it looks OK, I agree it can be merged.
Tree-SHA512: fbcd6cdc551770ff67d1df65ab171ce43c9eb7e7668da76da5c5b06865ed550527abcff661741a86c1535018a85a165619ff94ae3e6c7a695374b6c4f843c5ca
By specifying the `datacarriersize` option instead of the more
generic `acceptnonstdtxn`, we can be more specific about what
part of the transaction is non-standard and can be sure that all
other aspects follow the standard policy.
25e4762ae7 wallet: more accurate tx_noinputs_size (S3RK)
Pull request description:
Rationale: more accurate non-input fee estimation for txs with >=253 inputs
ACKs for top commit:
laanwj:
Concept and code review ACK 25e4762ae7
achow101:
ACK 25e4762ae7
furszy:
Code review ACK 25e4762a. left a small nit.
Tree-SHA512: bda8fad725d32ad3e13c007fa56ddb6679ac1a32098ddb08d9a114054acfa681cb66cd703ac675297f731cb381b09067a99a4efa31320140bbdd03f0cfdc81af
Transactions with more than one datacarrier (OP_RETURN) output
are never considered standard, i.e. this change is necessary in
order to to get rid of the `acceptnonstdtxn` option for some
tests.
af56d63eca Revert "bnb: exit selection when best_waste is 0" (Murch)
Pull request description:
This reverts commit 9b5950db86.
Waste can be negative. At feerates lower than long_term_feerate this
means that a waste of 0 may be a suboptimal solution and this causes the
search to exit prematurely.
Only when the feerate is equal to the long_term_feerate would achieving
a waste of 0 indicate that we have achieved an optimal solution,
because it would mean that the excess is 0. It seems unlikely
that this would ever occur outside of test cases, and even then we
should prefer solutions with more inputs over solutions with fewer
according to previous decisions—but solutions with more inputs are found
later in the branch exploration.
The "optimization" described in #18257 and implemented in #18262 is
therefore a premature exit on a suboptimal solution and should be reverted.
ACKs for top commit:
sipa:
utACK af56d63eca
S3RK:
utACK af56d63eca
achow101:
ACK af56d63eca
glozow:
utACK af56d63eca, agree it is incorrect to stop here unless we could rule out the possibility of a better solution with negative waste. `SelectCoinsBnB` doesn't know what long term feerate and effective feerate are (and probably shouldn't) so it's better to have no exit early condition at all.
Tree-SHA512: 470f1a49041a0042cb69d239fccac7512ace79871d43508b6e7f7a2f3aca3523930b16e00c5513b816d5fe078d9ab53e42b0a80fd3c3d48e6434f24c2b009077
4e569c8bd8 guix: remove explicit glibc stack protector disabling (fanquake)
Pull request description:
While glibc 2.25 and newer *can* be built with stack-smashing-protection
enabled, it isn't used by default, and still isn't, as of glibc 2.35,
so I can't see a reason to explicitly disable it.
I'd also like to move in the direction of enabling, by default,
hardening options for the toolchains we build, so removing the explicit
disabling is a step in that direction.
Will be following up with some changes based on this change.
Guix Build (x86_64):
```bash
954b393f5c775919e32b725a45aa93af8a5e75ead348f904304c0367583b41ff guix-build-4e569c8bd85e/output/aarch64-linux-gnu/SHA256SUMS.part
0ff27062ba2ac4c11a966de2d9aea070f54ab5c255068dd992b19fcb33661ffd guix-build-4e569c8bd85e/output/aarch64-linux-gnu/bitcoin-4e569c8bd85e-aarch64-linux-gnu-debug.tar.gz
bf48baf97e21467ce439f6e733cf3a20732adee01bb1d98aa9519c2ec54b5f41 guix-build-4e569c8bd85e/output/aarch64-linux-gnu/bitcoin-4e569c8bd85e-aarch64-linux-gnu.tar.gz
041eac2a2e045e2283cc78361adcc2232c5eecc9ad465624499225a4ad44f5fe guix-build-4e569c8bd85e/output/arm-linux-gnueabihf/SHA256SUMS.part
7a3bbca762f6c3c4fd851fbf74a2f00c21d98c211de5baa06d0ba2fc59505694 guix-build-4e569c8bd85e/output/arm-linux-gnueabihf/bitcoin-4e569c8bd85e-arm-linux-gnueabihf-debug.tar.gz
89e0260075472d10d02de7e3bb382d87f9ffb3d548f533aab0ba7e39f4c796df guix-build-4e569c8bd85e/output/arm-linux-gnueabihf/bitcoin-4e569c8bd85e-arm-linux-gnueabihf.tar.gz
96f893eefaa9fb5af41f46eece3831a3956a5a9ab1f825e4c17c5675bd020bbe guix-build-4e569c8bd85e/output/arm64-apple-darwin/SHA256SUMS.part
65865e481d33e1023adef769ca9a38ca8cdf03e8476a61f1724bb1ab0bc54750 guix-build-4e569c8bd85e/output/arm64-apple-darwin/bitcoin-4e569c8bd85e-arm64-apple-darwin-unsigned.dmg
38da0510c34d9c2bff98da60c873593c6a85bc6f73025990daaa8d5b022819c0 guix-build-4e569c8bd85e/output/arm64-apple-darwin/bitcoin-4e569c8bd85e-arm64-apple-darwin-unsigned.tar.gz
a1b5ccda7780df15fda2131d260542e57601fed2c18092edaa3094c23eafd99d guix-build-4e569c8bd85e/output/arm64-apple-darwin/bitcoin-4e569c8bd85e-arm64-apple-darwin.tar.gz
f1e4fb6d96420865ee1cfdc10960d8b0407ae49d367d5df1901510a8a87a69bf guix-build-4e569c8bd85e/output/dist-archive/bitcoin-4e569c8bd85e.tar.gz
5cc5e3193435bdd0aafc1a43e1dfc7582e585a27453e92e3383ceb8ba6c162ad guix-build-4e569c8bd85e/output/powerpc64-linux-gnu/SHA256SUMS.part
56bfeecb15b0c59dcccb31d1d5df978e7bb9c60bc0661638af7b263958cb8d4d guix-build-4e569c8bd85e/output/powerpc64-linux-gnu/bitcoin-4e569c8bd85e-powerpc64-linux-gnu-debug.tar.gz
46e61a752ba3ac1e553c82f4615854c27b38b9c2e5abd318840d3d5383e1384d guix-build-4e569c8bd85e/output/powerpc64-linux-gnu/bitcoin-4e569c8bd85e-powerpc64-linux-gnu.tar.gz
52ea9adf7b3a88fa88e89b53852d1d7917af959bee0b67c218959b1123f67c57 guix-build-4e569c8bd85e/output/powerpc64le-linux-gnu/SHA256SUMS.part
2a1a65bd55cc9c83ccbb296e7fe41d5b313466cf8d70ef8aec81aa47e346e422 guix-build-4e569c8bd85e/output/powerpc64le-linux-gnu/bitcoin-4e569c8bd85e-powerpc64le-linux-gnu-debug.tar.gz
b8dbcf97a83a1dd53d23eeafa714e3a3cb8d0b087c060978137e47fdab2b261f guix-build-4e569c8bd85e/output/powerpc64le-linux-gnu/bitcoin-4e569c8bd85e-powerpc64le-linux-gnu.tar.gz
87e3823e246e139ad14c4d44c8e2ed5e1bebea1a02d3931e66232505a1b35463 guix-build-4e569c8bd85e/output/riscv64-linux-gnu/SHA256SUMS.part
1307b92c608b1001628fda1792fbcb61183286cff707be930bcb1d887f5a4b02 guix-build-4e569c8bd85e/output/riscv64-linux-gnu/bitcoin-4e569c8bd85e-riscv64-linux-gnu-debug.tar.gz
0f660a9165a26f627be913e6bf1bb81cbabebee742031d0a75131a7e380e6c8a guix-build-4e569c8bd85e/output/riscv64-linux-gnu/bitcoin-4e569c8bd85e-riscv64-linux-gnu.tar.gz
d530151878bdf70c0913a12ba1aa49dad9ba62ac9edd70cda3982fd0fe327e93 guix-build-4e569c8bd85e/output/x86_64-apple-darwin/SHA256SUMS.part
dc3a9ee571854066ea03d60c1f2b8012fdff12ea1e74ab4ce02b1effc6689436 guix-build-4e569c8bd85e/output/x86_64-apple-darwin/bitcoin-4e569c8bd85e-x86_64-apple-darwin-unsigned.dmg
94c0522390e5650d91d63c6afa5bce895a60c17c1365e0d87a898c2868093dc9 guix-build-4e569c8bd85e/output/x86_64-apple-darwin/bitcoin-4e569c8bd85e-x86_64-apple-darwin-unsigned.tar.gz
364d72282e8824d5dffe184fc10bdcbc9cdf96e8c0ac379b8392e1e1992e3307 guix-build-4e569c8bd85e/output/x86_64-apple-darwin/bitcoin-4e569c8bd85e-x86_64-apple-darwin.tar.gz
0d3ce4cbf3444fc9a3c488f12ef7b73d07b85bcf3d4d9500b689d44506a79818 guix-build-4e569c8bd85e/output/x86_64-linux-gnu/SHA256SUMS.part
f584d494db5594ae2bc06e09f8e68c11e446bc82cb8a1dfa6afee5d3a079b5af guix-build-4e569c8bd85e/output/x86_64-linux-gnu/bitcoin-4e569c8bd85e-x86_64-linux-gnu-debug.tar.gz
ea0e9316dd25ebee9023f3c65cb99fe846de6fe56152d4926005f9da500a502c guix-build-4e569c8bd85e/output/x86_64-linux-gnu/bitcoin-4e569c8bd85e-x86_64-linux-gnu.tar.gz
a41966b6d13aa1e702cc357bbedfd51bcb431caa39bb904efd9611e3a945bf1c guix-build-4e569c8bd85e/output/x86_64-w64-mingw32/SHA256SUMS.part
5f150613204341d91a4b755c74120e233567187ba4f9151a12e39e5304efb3a1 guix-build-4e569c8bd85e/output/x86_64-w64-mingw32/bitcoin-4e569c8bd85e-win64-debug.zip
6a94dc9c5dcb2a4448a37573baab50f405e08af0d5a4de8a8046cba5445153e4 guix-build-4e569c8bd85e/output/x86_64-w64-mingw32/bitcoin-4e569c8bd85e-win64-setup-unsigned.exe
31fe85ba31ed84ebbbc4cc42f593e1de1811c1ecc9a0a094d05b0914bd151174 guix-build-4e569c8bd85e/output/x86_64-w64-mingw32/bitcoin-4e569c8bd85e-win64-unsigned.tar.gz
0a6d590c26a47c51192e4003ad97ecd6b7ad91c8f8612ea310fb324bce5dc15a guix-build-4e569c8bd85e/output/x86_64-w64-mingw32/bitcoin-4e569c8bd85e-win64.zip
```
Guix Build (arm64):
```bash
2ce621cb469772c318a29b21bc4dd546353130a688a5ecb66373256c7be2c37a guix-build-4e569c8bd85e/output/arm-linux-gnueabihf/SHA256SUMS.part
13abe55069581ca711529d058a8e5de732c6630a94b7e912e9c31f606241c264 guix-build-4e569c8bd85e/output/arm-linux-gnueabihf/bitcoin-4e569c8bd85e-arm-linux-gnueabihf-debug.tar.gz
7a60cd7d9aee30bc8e08cf9d52bd032f82e48214c81130e2f61ca3da71c01477 guix-build-4e569c8bd85e/output/arm-linux-gnueabihf/bitcoin-4e569c8bd85e-arm-linux-gnueabihf.tar.gz
d614a4acfed70f61814a5c26bf51594e0cc666fc3dadc3df805e5cc608835550 guix-build-4e569c8bd85e/output/arm64-apple-darwin/SHA256SUMS.part
c9d5705b947c461ade878d7a0110ae5b34b384991f5bf6e86db0b79f421d4f81 guix-build-4e569c8bd85e/output/arm64-apple-darwin/bitcoin-4e569c8bd85e-arm64-apple-darwin-unsigned.dmg
c1897d204e75b9ef8a58fb3f2c85d9c306b05dbd6c8f74a2b4ccfbd85aed5574 guix-build-4e569c8bd85e/output/arm64-apple-darwin/bitcoin-4e569c8bd85e-arm64-apple-darwin-unsigned.tar.gz
1c9e188d76c18785d4500c1c7ab0e049cf35c878803266580913e8cc4bd01bf6 guix-build-4e569c8bd85e/output/arm64-apple-darwin/bitcoin-4e569c8bd85e-arm64-apple-darwin.tar.gz
f1e4fb6d96420865ee1cfdc10960d8b0407ae49d367d5df1901510a8a87a69bf guix-build-4e569c8bd85e/output/dist-archive/bitcoin-4e569c8bd85e.tar.gz
f3e7d6b6aca3ca4f150e0e91e9532f4eb21c4f60ab1c21b6ecfaa9c862f9f8a8 guix-build-4e569c8bd85e/output/powerpc64-linux-gnu/SHA256SUMS.part
48e630949976ee298bccf01cfbbb7fea29c9bd0bc658cf0564d4a3e1997556e8 guix-build-4e569c8bd85e/output/powerpc64-linux-gnu/bitcoin-4e569c8bd85e-powerpc64-linux-gnu-debug.tar.gz
9e30c4987f3657ba6499a78c5c578e430c55f71991fc9ad6f3ecf4847ed1814e guix-build-4e569c8bd85e/output/powerpc64-linux-gnu/bitcoin-4e569c8bd85e-powerpc64-linux-gnu.tar.gz
128ce9194e377b013baceafc4ddba0f70c239e36057c9dc0a9213caa34c5064f guix-build-4e569c8bd85e/output/powerpc64le-linux-gnu/SHA256SUMS.part
8e4a41c07e9427de4054069c3af668157372cc6cd86d758c0b35b7ed906e5365 guix-build-4e569c8bd85e/output/powerpc64le-linux-gnu/bitcoin-4e569c8bd85e-powerpc64le-linux-gnu-debug.tar.gz
da6924709b35f7fbaf9b7b772e0f14be5b583e9453b0cae58b6a5b1e159580c7 guix-build-4e569c8bd85e/output/powerpc64le-linux-gnu/bitcoin-4e569c8bd85e-powerpc64le-linux-gnu.tar.gz
2415604bf3651ea18dcbb4ec5bf73372bdc19c80aa316b864de20c8a5df4bf34 guix-build-4e569c8bd85e/output/riscv64-linux-gnu/SHA256SUMS.part
8f6ee4b69fb33b40ad505c091684258ded340ab9936b554f8fa4e499d4da1155 guix-build-4e569c8bd85e/output/riscv64-linux-gnu/bitcoin-4e569c8bd85e-riscv64-linux-gnu-debug.tar.gz
0a941d44532287288a9859c35fdaa940c940c1e8f4a17b7994e3796c9a668d57 guix-build-4e569c8bd85e/output/riscv64-linux-gnu/bitcoin-4e569c8bd85e-riscv64-linux-gnu.tar.gz
d530151878bdf70c0913a12ba1aa49dad9ba62ac9edd70cda3982fd0fe327e93 guix-build-4e569c8bd85e/output/x86_64-apple-darwin/SHA256SUMS.part
dc3a9ee571854066ea03d60c1f2b8012fdff12ea1e74ab4ce02b1effc6689436 guix-build-4e569c8bd85e/output/x86_64-apple-darwin/bitcoin-4e569c8bd85e-x86_64-apple-darwin-unsigned.dmg
94c0522390e5650d91d63c6afa5bce895a60c17c1365e0d87a898c2868093dc9 guix-build-4e569c8bd85e/output/x86_64-apple-darwin/bitcoin-4e569c8bd85e-x86_64-apple-darwin-unsigned.tar.gz
364d72282e8824d5dffe184fc10bdcbc9cdf96e8c0ac379b8392e1e1992e3307 guix-build-4e569c8bd85e/output/x86_64-apple-darwin/bitcoin-4e569c8bd85e-x86_64-apple-darwin.tar.gz
047d3eae54136b7f5fb20487fb2c57455dda6bb88594065b71843400fbc41824 guix-build-4e569c8bd85e/output/x86_64-linux-gnu/SHA256SUMS.part
8bfb97bcab8d5e0a86a2a8d20be5215d8bb615a8b6c3ad69e1db5028caf2dd29 guix-build-4e569c8bd85e/output/x86_64-linux-gnu/bitcoin-4e569c8bd85e-x86_64-linux-gnu-debug.tar.gz
4962550d7d113e8544a33e2ffa5a0e77e172984c17bfa461a631bf08dc7cc545 guix-build-4e569c8bd85e/output/x86_64-linux-gnu/bitcoin-4e569c8bd85e-x86_64-linux-gnu.tar.gz
5ad1661c475308c6df102aee51261e36583fe0f5f73713d7f19384b63755a3c5 guix-build-4e569c8bd85e/output/x86_64-w64-mingw32/SHA256SUMS.part
62cf3e15e638f48bd0931a847ba5e5636422fb6bd00da41251c1f636d39c5822 guix-build-4e569c8bd85e/output/x86_64-w64-mingw32/bitcoin-4e569c8bd85e-win64-debug.zip
6a94dc9c5dcb2a4448a37573baab50f405e08af0d5a4de8a8046cba5445153e4 guix-build-4e569c8bd85e/output/x86_64-w64-mingw32/bitcoin-4e569c8bd85e-win64-setup-unsigned.exe
31fe85ba31ed84ebbbc4cc42f593e1de1811c1ecc9a0a094d05b0914bd151174 guix-build-4e569c8bd85e/output/x86_64-w64-mingw32/bitcoin-4e569c8bd85e-win64-unsigned.tar.gz
a3c7db0ca4b557810b5e5f1ec14cecaf47b5bf51631798d8675243bb6ecedf8f guix-build-4e569c8bd85e/output/x86_64-w64-mingw32/bitcoin-4e569c8bd85e-win64.zip
```
ACKs for top commit:
laanwj:
Code review ACK 4e569c8bd8
Tree-SHA512: 7f75c304ec67d824ce17be1acb0d67c3946cc346444abcac0a13762365566d101aa784f92dd28ef15b664f1a5f64ae1f60ca91b2538de7ea08a7684bf33cda0d
d1684beabe fees: Pass in a filepath instead of referencing gArgs (Carl Dong)
9a3d825c30 init: Remove redundant -*mempool*, -limit* queries (Carl Dong)
6c5c60c412 mempool: Use m_limit for UpdateTransactionsFromBlock (Carl Dong)
9e93b10301 node/ifaces: Use existing MemPoolLimits (Carl Dong)
38af2bcf35 mempoolaccept: Use limits from mempool in constructor (Carl Dong)
9333427014 mempool: Introduce (still-unused) MemPoolLimits (Carl Dong)
716bb5fbd3 scripted-diff: Rename anc/desc size limit vars to indicate SI unit (Carl Dong)
1ecc77321d scripted-diff: Rename DEFAULT_MEMPOOL_EXPIRY to indicate time unit (Carl Dong)
aa9141cd81 mempool: Pass in -mempoolexpiry instead of referencing gArgs (Carl Dong)
51c7a41a5e init: Only determine maxmempool once (Carl Dong)
386c9472c8 mempool: Make GetMinFee() with custom size protected (Carl Dong)
82f00de7a6 mempool: Pass in -maxmempool instead of referencing gArgs (Carl Dong)
f1941e8bfd pool: Add and use MemPoolOptions, ApplyArgsManOptions (Carl Dong)
0199bd35bb fuzz/rbf: Add missing TestingSetup (Carl Dong)
ccbaf546a6 scripted-diff: Rename DEFAULT_MAX_MEMPOOL_SIZE to indicate SI unit (Carl Dong)
fc02f77ca6 ArgsMan: Add Get*Arg functions returning optional (Carl Dong)
Pull request description:
This is part of the `libbitcoinkernel` project: #24303, https://github.com/bitcoin/bitcoin/projects/18
-----
As mentioned in the Stage 1 Step 2 description of [the `libbitcoinkernel` project](https://github.com/bitcoin/bitcoin/issues/24303), `ArgsManager` will not be part of `libbitcoinkernel`. Therefore, it is important that we remove any dependence on `ArgsManager` by code that will be part of `libbitcoinkernel`. This is the first in a series of PRs aiming to achieve this.
This PR removes `CTxMemPool+MempoolAccept`'s dependency on `ArgsManager` by introducing a `CTxMemPool::Options` struct, which is used to specify `CTxMemPool`'s various options at construction time.
These options are:
- `-maxmempool` -> `CTxMemPool::Options::max_size`
- `-mempoolexpiry` -> `CTxMemPool::Options::expiry`
- `-limitancestorcount` -> `CTxMemPool::Options::limits::ancestor_count`
- `-limitancestorsize` -> `CTxMemPool::Options::limits::ancestor_size`
- `-limitdescendantcount` -> `CTxMemPool::Options::limits::descendant_count`
- `-limitdescendantsize` -> `CTxMemPool::Options::limits::descendant_size`
More context can be gleaned from the commit messages. The important commits are:
- 56eb479ded8bfb2ef635bb6f3b484f9d5952c70d "pool: Add and use MemPoolOptions, ApplyArgsManOptions"
- a1e08b70f3068f4e8def1c630d8f50cd54da7832 "mempool: Pass in -maxmempool instead of referencing gArgs"
- 6f4bf3ede5812b374828f08fc728ceded2f10024 "mempool: Pass in -mempoolexpiry instead of referencing gArgs"
- 5958a7fe4806599fc620ee8c1a881ca10fa2dd16 "mempool: Introduce (still-unused) MemPoolLimits"
Reviewers: Help needed in the following commits (see commit messages):
- a1e08b70f3068f4e8def1c630d8f50cd54da7832 "mempool: Pass in -maxmempool instead of referencing gArgs"
- 0695081a797e9a5d7787b78b0f8289dafcc6bff7 "node/ifaces: Use existing MemPoolLimits"
Note to Reviewers: There are perhaps an infinite number of ways to architect `CTxMemPool::Options`, the current one tries to keep it simple, usable, and flexible. I hope we don't spend too much time arguing over the design here since that's not the point. In the case that you're 100% certain that a different design is strictly better than this one in every regard, please show us a fully-implemented branch.
-----
TODO:
- [x] Use the more ergonomic `CTxMemPool::Options` where appropriate
- [x] Doxygen comments for `ApplyArgsManOptions`, `MemPoolOptions`
-----
Questions for Reviewers:
1. Should we use `std::chrono::seconds` for `CTxMemPool::Options::expiry` and `CTxMemPool::m_expiry` instead of an `int64_t`? Something else? (`std::chrono::hours`?)
2. Should I merge `CTxMemPool::Limits` inside `CTxMemPool::Options`?
ACKs for top commit:
MarcoFalke:
ACK d1684beabe🍜
ryanofsky:
Code review ACK d1684beabe. Just minor cleanups since last review, mostly switching to brace initialization
Tree-SHA512: 2c138e52d69f61c263f1c3648f01c801338a8f576762c815f478ef5148b8b2f51e91ded5c1be915e678c0b14f6cfba894b82afec58d999d39a7bb7c914736e0b
ac4fb3bbbe gui: reset options, notify user about the backup creation (furszy)
Pull request description:
Quick follow-up to first point of https://github.com/bitcoin-core/gui/pull/602#pullrequestreview-1002780997
ACKs for top commit:
ryanofsky:
Code review ACK ac4fb3bbbe, just fixing displayed backup directory since last review
jarolrod:
tACK ac4fb3bbbe
Tree-SHA512: cfeca5cd6d6d3d69bbd81211cf1bfd490de13ac96bf53be081a5ceb88611afa57dff2be35f8e0a41b1088b7b892f75a21a9abf47f2e1d77e9e316467eb7c12be
This reverts commit 9b5950db86.
Waste can be negative. At feerates lower than long_term_feerate this
means that a waste of 0 may be a suboptimal solution and this causes the
search to exit prematurely.
Only when the feerate is equal to the long_term_feerate would achieving
a waste of 0 indicate that we have achieved an optimal solution,
because it would mean that the excess is 0. It seems unlikely
that this would ever occur outside of test cases, and even then we
should prefer solutions with more inputs over solutions with fewer
according to previous decisions—but solutions with more inputs are found
later in the branch exploration.
The "optimization" described in #18257 and implemented in #18262 is
therefore a premature exit on a suboptimal solution and should be reverted.
Change getheaders messages so that we wait up to 2 minutes for a response to a
prior getheaders message before issuing a new one.
Also change the handling of the getheaders message sent in response to a block
INV, so that we no longer use the hashstop variable (including the hash stop
will just mean that if our peer's headers chain is longer, then we won't learn
it, so there's no benefit to using hashstop).
Also, now respond to a getheaders during IBD with an empty headers message
(rather than nothing) -- this better conforms to the intent of the new logic
that it's better to not ignore a peer's getheaders message, even if you have
nothing to give. This also avoids a lot of functional tests breaking.
p2p_segwit.py is modified to use this same strategy, as the test logic (of
expecting a getheaders after a block inv) would otherwise be broken.
Also moves the call to happen directly after validation of a headers message
(rather than mixed in with other state updates for the peer), and removes an
incorrect comment in favor of one that explains why headers sync must continue
from the last header a peer has sent.
Since:
- UpdateTransactionsFromBlock is only called by
MaybeUpdateMempoolForReorg, which calls it with the gArgs-determined
ancestor limits
- UpdateForDescendants is only called by UpdateTransactionsFromBlock
with the ancestor limits unchanged
We can remove the requirement to specify the ancestor limits for both
UpdateTransactionsFromBlock and UpdateForDescendants and just use the
values in the m_limits member.
Also move some removed comments to MemPoolLimits struct members.
The uint64_t cast in UpdateForDescendants is not new behavior,
see the diff in CChainState::MaybeUpdateMempoolForReorg for where they
were previously.
Better to be explicit when it comes to sizes to avoid unintentional
bugs. We use MB and KB all over the place.
-BEGIN VERIFY SCRIPT-
find_regex="DEFAULT_(ANCESTOR|DESCENDANT)_SIZE_LIMIT" \
&& git grep -l -E "$find_regex" \
| xargs sed -i -E "s@$find_regex@\0_KVB@g"
-END VERIFY SCRIPT-
Better to be explicit when it comes to time to avoid unintentional bugs.
-BEGIN VERIFY SCRIPT-
find_regex="DEFAULT_MEMPOOL_EXPIRY" \
&& git grep -l -E "$find_regex" \
| xargs sed -i -E "s@$find_regex@\0_HOURS@g"
-END VERIFY SCRIPT-
