dc02edcba1 doc: update the URLs to thread functions in developer-notes (Vasil Dimov)
c5cc3f140c doc: list the I2P accept thread in developer-notes (Vasil Dimov)
Pull request description:
Document `i2paccept` in `doc/developer-notes.md` and fix broken URLs to doxygen.bitcoincore.org.
ACKs for top commit:
theStack:
re-ACK dc02edcba1
Tree-SHA512: 7d396885dd2e8fda2b050aaa25a82b4217ced6a5aa3478339fb892d5392d2b8b6b5997f8bb9acaab7867c0c5bf58bd0b720ef36b335b1e7eb617b8fc205915b0
d3e9a1c71b doc: update for NetBSD 9.2, add GUI Build Instructions (Jarol Rodriguez)
Pull request description:
**For reviewer:** as I suppose few have a NetBSD system available, I wrote a [guide](https://gist.github.com/jarolrod/385dc063bb02c90aea0cbe8a147fc418#file-netbsd-vm-setup-guide-md) to setup a VM for testing purposes.
This attempts to update the NetBSD docs so one can successfully build on the latest release. It also adds instructions to build the GUI.
Additionally, it includes a note and an example on how one could update the gcc version bundled with NetBSD 9.2 and prior to be able to actually compile. This note can be updated with the release of NetBSD 10, as it will package an acceptable gcc version.
Master: [render](https://github.com/bitcoin/bitcoin/blob/master/doc/build-netbsd.md)
PR: [render](d3e9a1c71b/doc/build-netbsd.md)
Related to #20610, but reworked.
ACKs for top commit:
aureleoules:
ACK d3e9a1c71b.
fanquake:
ACK d3e9a1c71b
Tree-SHA512: fc3c12689cee886f26782c1d57f3b794ceaedc965a571dd06cfc4a57f90393842ad2124e6dba55a12ac9de9bf63d8e3eb4aa541768f2aa8603248175ce7d1c08
4c9666bd73 Mention `mempoolfullrbf` in policy/mempool-replacements.md (Antoine Riard)
aae66ab43d Update getmempoolinfo RPC with `mempoolfullrbf` (Antoine Riard)
3e27e31727 Introduce `mempoolfullrbf` node setting. (Antoine Riard)
Pull request description:
This is ready for review.
Recent discussions among LN devs have brought back on the surface concerns about the security of multi-party funded transactions against pinnings attacks and other mempool-based nuisances. The lack of full-rbf transaction-relay topology connected to miners open the way to cheap and naive DoS against multi-party funded transactions (e.g coinjoins, dual-funded channels, on-chain DLCs, ...) without solutions introducing an overhead cost or centralization vectors afaik . For more details, see [0].
This PR implements a simple `fullrbf` setting, where the node always allows transaction replacement, ignoring BIP125 opt-in flag. The default value of the setting stays **false**, therefore opt-in replacement is still the default Bitcoin Core replacement policy. Contrary to a previous proposal of mine and listening to feedbacks collected since then [1], I think this new setting simply offers more flexibility in a node transaction-relay policy suiting one's application requirements, without arguing a change of the default behavior.
I [posted](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html) on the ML to invite operators with a bitcoin application sensitive to full-rbf (e.g dual-funded LN channels service providers) or mempool researchers to join a bootstrapped full-rbf activated peers network for experimentation and learning. If people have strong opinions against the existence of such full-rbf transaction-relay network, I'm proposing to express them on the future thread.
[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html
Follow-up suggestions :
- soft-enable opt-in RBF in the wallet : https://github.com/bitcoin/bitcoin/pull/25353#issuecomment-1154918789
- p2p discovery and additional outbound connection to full-rbf peers : https://github.com/bitcoin/bitcoin/pull/25353#issuecomment-1156044401
- match the code between RPC, wallet and mempool about disregard of inherited signaling : #22698
ACKs for top commit:
instagibbs:
reACK 4c9666bd73
glozow:
ACK 4c9666bd73, a few nits which are non-blocking.
w0xlt:
ACK 4c9666bd73
Tree-SHA512: 9e288bf22e06a9808804e58178444ef1830c3fdd42fd8a7cd7ffb101f8f586e08b000679be407d63ca76a56f7216227b368ff630c81f3fac3243db1a1202ab1c
NetBSD doc has not seen any meaningful contribution since 2018.
This PR intends to update the docs so that one can successfully build on
the latest NetBSD release. It also adds dependency information and
instructions to build the GUI.
No reason to have this here with outdated information. We already point
users to the depends readme, the doc cross builders should be pointed to
, within this doc.
f67b6fce37 Update Arch Linux build example (Igor Bubelov)
Pull request description:
The current build example has two issues:
1. The claim that the wallet functionality will be missing is obsolete since Bitcoin Core can use SQLite, which is a hard dependency of `pacman` so we can assume that it's always present.
2. Installing package groups such as `base-devel` adds some friction and uncertainty by forcing readers to choose which packages they need, interactively. Listing required deps explicitly speeds up the whole process, makes it more transparent and cuts the number of installed packages.
ACKs for top commit:
laanwj:
re-ACK f67b6fce37
Tree-SHA512: c068dac5d244044827d5d94a4b48f239180301b6870dce31b003fa111a69f7e3a483681a7ea2b3d393d6791b40043685ce2fe62c338cce1b7e37a6db0f02b1a2
d873ff96e5 refactor: cleanups post unsubtree'ing univalue (fanquake)
e2aa7047f9 refactor: un-subtree univalue (fanquake)
Pull request description:
At this point, maintaining Univalue as a subtree doesn’t serve much purpose, other than being an inconvenience for making changes to the code (along with polluting our repo with a number of files we don’t use). Our [Univalue fork](https://github.com/bitcoin-core/univalue-subtree) currently deviates from the [upstream API](https://github.com/jgarzik/univalue), and for some time has been marked as not-maintained for use by other projects (I'm not aware of any that use it). The upstream Univalue is not maintained, and has not been for some time. There are no new releases, bugs remain unfixed, and PR's we've upstreamed, https://github.com/jgarzik/univalue/pulls, are not being commented on/merged.
Another substantial benefit of no-longer maintaining a subtree is removing the rather awkward work-flow currently required to make changes to the Univalue code, particularly breaking changes / introducing new features, e.g. https://github.com/bitcoin-core/univalue-subtree/pull/27. We need to dance around and merge changes to our fork, with a flag, then pull them down here, then switch to using the new code, then go back to our Univalue repo, and remove the old code / flag, then pull the repo down here again, and remove our usage of the flag. Quite the overcomplicated mess.
With this PR I'm proposing we stop treating Univalue like a subtree, or upstream project/fork, and going forward, treat it as part of this codebase, which we can refactor directly (with pulls to this repo. Ideally, after this is merged, our univalue subtree repo could be marked as "archived". In this repo, I think there is a good chance that the Univalue code will ultimately be refactored away into "modern" C++, i.e using `std::variant` (at least one person has played around with doing this).
Univalue history:
- Subtree first introduced: https://github.com/bitcoin/bitcoin/pull/6637
- `--system-univalue` option introduced: https://github.com/bitcoin/bitcoin/pull/7349
Suggestion was to use system Univalue by default.
This was pushed back on by contributors, as well as the [upstream Univalue](https://github.com/jgarzik/univalue) maintainer (jgarzik).
- Our fork's README was updated to say `It is not maintained for usage by other projects. Notably, the API may break in non-backward-compatible ways.` : https://github.com/bitcoin-core/univalue-subtree/pull/17
- Our fork README additionally updated to say `the API is broken in non-backward-compatible ways.` : https://github.com/bitcoin-core/univalue-subtree/pull/30
- `--system-univalue` option removed: https://github.com/bitcoin/bitcoin/pull/22646
- Univalue "subtree" removed: This PR.
Guix Build (x86_64):
```bash
06748985a9a386457d10a411b5afe1d59536e5653ec9c5bc8ac8410cd715d073 guix-build-d873ff96e51a/output/aarch64-linux-gnu/SHA256SUMS.part
57d81891f6d4ae417dd3bcbfc90839600e103da9c7d7b09dbebb82f0119241f3 guix-build-d873ff96e51a/output/aarch64-linux-gnu/bitcoin-d873ff96e51a-aarch64-linux-gnu-debug.tar.gz
7bb70d3b67253f5e8e5af8158bbf1b4b3e25e782f951d3defb7976534ae67d62 guix-build-d873ff96e51a/output/aarch64-linux-gnu/bitcoin-d873ff96e51a-aarch64-linux-gnu.tar.gz
b1acb90877d6e3b8d4bd2d57103889e0474263e4153f302eba8cb304fd1aecd7 guix-build-d873ff96e51a/output/arm-linux-gnueabihf/SHA256SUMS.part
91f9f65aebc131522cae5b523359c62e402a2c929670e1cca19d6a2760d29e04 guix-build-d873ff96e51a/output/arm-linux-gnueabihf/bitcoin-d873ff96e51a-arm-linux-gnueabihf-debug.tar.gz
1fc3ed39bfc95592503b8dd11f468240deca4fb757f9adb08a0f07f5c0690837 guix-build-d873ff96e51a/output/arm-linux-gnueabihf/bitcoin-d873ff96e51a-arm-linux-gnueabihf.tar.gz
a5cf5bd0ee0de92fb03f6bca91cfa6667ed77885112e71dd92a82bbd8670141e guix-build-d873ff96e51a/output/arm64-apple-darwin/SHA256SUMS.part
f6715399cebb5ac0a09f190fe805146c13d1e8eba57401541d0628da3badc588 guix-build-d873ff96e51a/output/arm64-apple-darwin/bitcoin-d873ff96e51a-arm64-apple-darwin-unsigned.dmg
07cf82cab4e459ed4e862fc3a2903e49ac750adc6b6fe0534ec165f00e666230 guix-build-d873ff96e51a/output/arm64-apple-darwin/bitcoin-d873ff96e51a-arm64-apple-darwin-unsigned.tar.gz
81bc076aa415183109e2848fa3cc0265b34f6af3e75b76bcbc6cff524db76a0f guix-build-d873ff96e51a/output/arm64-apple-darwin/bitcoin-d873ff96e51a-arm64-apple-darwin.tar.gz
8751b05a3395d668e31217c92cbce9c131aa3566b3784a7e3544adf34fc89fe8 guix-build-d873ff96e51a/output/dist-archive/bitcoin-d873ff96e51a.tar.gz
526b7780a16a3de3c6006606d3d7a8c2ca565ef28669e2f6f303349a252e4977 guix-build-d873ff96e51a/output/powerpc64-linux-gnu/SHA256SUMS.part
ff917a50d2b20d41a5954e1ba1e8fb39498a9c8867828483af3f501573148ede guix-build-d873ff96e51a/output/powerpc64-linux-gnu/bitcoin-d873ff96e51a-powerpc64-linux-gnu-debug.tar.gz
0311455c821ad392013fc3999a2b2d027fdb5c28e7eb6c3fea9cec29f3730d2d guix-build-d873ff96e51a/output/powerpc64-linux-gnu/bitcoin-d873ff96e51a-powerpc64-linux-gnu.tar.gz
983c2553990eb7cebb26e1a0a3e5a9308259dea60d0b64ab6782892d02a7abc1 guix-build-d873ff96e51a/output/powerpc64le-linux-gnu/SHA256SUMS.part
aba604827d969348671ec3f36dbf37469292715d3f756a7f44a0a5243dbe02f3 guix-build-d873ff96e51a/output/powerpc64le-linux-gnu/bitcoin-d873ff96e51a-powerpc64le-linux-gnu-debug.tar.gz
e450bd82020d5086f3bb0a23181263315cc05eaf6e5809d0a2115bff4e7ddb2e guix-build-d873ff96e51a/output/powerpc64le-linux-gnu/bitcoin-d873ff96e51a-powerpc64le-linux-gnu.tar.gz
476e8e2c80498b241af154abd9112bd2767110c0d6d7e9fa11761de716cb760f guix-build-d873ff96e51a/output/riscv64-linux-gnu/SHA256SUMS.part
a76435b3492efcd9af47ad652170605fad50691fd5aff2b46bce0bd08014879e guix-build-d873ff96e51a/output/riscv64-linux-gnu/bitcoin-d873ff96e51a-riscv64-linux-gnu-debug.tar.gz
83985d409cd90bf7120cf7902ee442595d28a1469b7c600b666ef901981e5190 guix-build-d873ff96e51a/output/riscv64-linux-gnu/bitcoin-d873ff96e51a-riscv64-linux-gnu.tar.gz
61c89850244ddf5813ff80c242eff89925d30bccadfa5cb63e968c3af49eb964 guix-build-d873ff96e51a/output/x86_64-apple-darwin/SHA256SUMS.part
cd219fab8918b061a342357d298aca0c044feb34c6d50a7851d5d3bf18cec267 guix-build-d873ff96e51a/output/x86_64-apple-darwin/bitcoin-d873ff96e51a-x86_64-apple-darwin-unsigned.dmg
1170d3fdb199fbfca2c20b2a77cc81a6fe24b7e4973543a4461e887f14ac68e9 guix-build-d873ff96e51a/output/x86_64-apple-darwin/bitcoin-d873ff96e51a-x86_64-apple-darwin-unsigned.tar.gz
71e93297ed8c581a7ed32a6948ef7b1ea2e7c43cb054181de3b5f604f7a2c28b guix-build-d873ff96e51a/output/x86_64-apple-darwin/bitcoin-d873ff96e51a-x86_64-apple-darwin.tar.gz
fc8b7b670de9d175775e73df47dc855581c873a9be4adf1d81a4dbb2831d5348 guix-build-d873ff96e51a/output/x86_64-linux-gnu/SHA256SUMS.part
5703b02c2647f9997aa5ca12514d6a54b1eb2e29046223ca062383326b95894f guix-build-d873ff96e51a/output/x86_64-linux-gnu/bitcoin-d873ff96e51a-x86_64-linux-gnu-debug.tar.gz
bab4b932b83476cf6fc2e0b5bf0d2203287f7fd0d1a968e325f2edd5b1d8415b guix-build-d873ff96e51a/output/x86_64-linux-gnu/bitcoin-d873ff96e51a-x86_64-linux-gnu.tar.gz
5d180b0415fa8e825d46928c168cb1ae6e27016841b2ff8e190bf13879a5545c guix-build-d873ff96e51a/output/x86_64-w64-mingw32/SHA256SUMS.part
d469695a32f6414b25fef7b5fdfda4d854071450ba25148a1dce468114fa9057 guix-build-d873ff96e51a/output/x86_64-w64-mingw32/bitcoin-d873ff96e51a-win64-debug.zip
2e7d4e533a5998863c115c586c61b75b4039cd329e12ed24cff78b7f16b6ea57 guix-build-d873ff96e51a/output/x86_64-w64-mingw32/bitcoin-d873ff96e51a-win64-setup-unsigned.exe
3dabbd627b532beef57c3d4b5bd30c93c5ea74c492918484cf24685aca8d7bc4 guix-build-d873ff96e51a/output/x86_64-w64-mingw32/bitcoin-d873ff96e51a-win64-unsigned.tar.gz
3a40660fba08f7632efd1f73c198f8298db33eab6ef5eaca88b997d95fc31f29 guix-build-d873ff96e51a/output/x86_64-w64-mingw32/bitcoin-d873ff96e51a-win64.zip
```
Guix Build (arm64):
```bash
0e764679199358fc321dcfcb58c6302e6518f55b3fd27bdd47f2da2a826ba16a guix-build-d873ff96e51a/output/arm-linux-gnueabihf/SHA256SUMS.part
5955d28e6d56e5a3297dab723b8478f1b0bb7f5b86476c581339122f34cc7f14 guix-build-d873ff96e51a/output/arm-linux-gnueabihf/bitcoin-d873ff96e51a-arm-linux-gnueabihf-debug.tar.gz
49c68bc0066f709be68f1e5731425d51fb3cb8062a24aa9fa599987165759cad guix-build-d873ff96e51a/output/arm-linux-gnueabihf/bitcoin-d873ff96e51a-arm-linux-gnueabihf.tar.gz
ca678d4eb27c9fa3c527211c0ccb145322a15f327545b5c82f1d1b8d3c310e5a guix-build-d873ff96e51a/output/arm64-apple-darwin/SHA256SUMS.part
38366d7fbd769b426f1097e966abe39f01a7ce743f6af1cd0f228b1801d3c87f guix-build-d873ff96e51a/output/arm64-apple-darwin/bitcoin-d873ff96e51a-arm64-apple-darwin-unsigned.dmg
0c05dc9c17f5d8237b3e003c2e4c715455c3868bd4cd014e2a15ceb152b27b9c guix-build-d873ff96e51a/output/arm64-apple-darwin/bitcoin-d873ff96e51a-arm64-apple-darwin-unsigned.tar.gz
32676e1f9f07f3f77143f8b6038c943da6ba93b081232ec52c2ff940f9f7cc88 guix-build-d873ff96e51a/output/arm64-apple-darwin/bitcoin-d873ff96e51a-arm64-apple-darwin.tar.gz
8751b05a3395d668e31217c92cbce9c131aa3566b3784a7e3544adf34fc89fe8 guix-build-d873ff96e51a/output/dist-archive/bitcoin-d873ff96e51a.tar.gz
bdae66515060cab0b362784f0b2019b77da0435f1732d3c91fabcfb5e8c675f6 guix-build-d873ff96e51a/output/powerpc64-linux-gnu/SHA256SUMS.part
8d837391310b4cdec2296a6e78a9f9b3ea2b3da7870881a5cedf86a3429c08c6 guix-build-d873ff96e51a/output/powerpc64-linux-gnu/bitcoin-d873ff96e51a-powerpc64-linux-gnu-debug.tar.gz
efe825d6f36338bd4c0b427901b72d666f819858fb241a4211f03bbb738f6961 guix-build-d873ff96e51a/output/powerpc64-linux-gnu/bitcoin-d873ff96e51a-powerpc64-linux-gnu.tar.gz
7494cf8c5f384ca3205b3ed44dd4c0edebcb9e0a6bf9c8e649fc6d99cc5a10b2 guix-build-d873ff96e51a/output/powerpc64le-linux-gnu/SHA256SUMS.part
8ceeb21d7fce9e164dbb47b35d0551b59819075fc44dcea39603132340f80c41 guix-build-d873ff96e51a/output/powerpc64le-linux-gnu/bitcoin-d873ff96e51a-powerpc64le-linux-gnu-debug.tar.gz
bfbbb20dc4e7b30444a52f5f57b5789b5d1edee80abdc8066129b48c59ee65c9 guix-build-d873ff96e51a/output/powerpc64le-linux-gnu/bitcoin-d873ff96e51a-powerpc64le-linux-gnu.tar.gz
65d578b81b00a1032039362dc6be1a71368f390188e0f948829afd03b8858ed2 guix-build-d873ff96e51a/output/riscv64-linux-gnu/SHA256SUMS.part
e5233d7e7a8832893ff414c78eb3d4bca3ae30d1a1f789a23419c6739b203022 guix-build-d873ff96e51a/output/riscv64-linux-gnu/bitcoin-d873ff96e51a-riscv64-linux-gnu-debug.tar.gz
fb6d9f5a063dc7752fcc2acc95a0052322d7c8c86d2c6373e0ceb949dcf22f49 guix-build-d873ff96e51a/output/riscv64-linux-gnu/bitcoin-d873ff96e51a-riscv64-linux-gnu.tar.gz
61c89850244ddf5813ff80c242eff89925d30bccadfa5cb63e968c3af49eb964 guix-build-d873ff96e51a/output/x86_64-apple-darwin/SHA256SUMS.part
cd219fab8918b061a342357d298aca0c044feb34c6d50a7851d5d3bf18cec267 guix-build-d873ff96e51a/output/x86_64-apple-darwin/bitcoin-d873ff96e51a-x86_64-apple-darwin-unsigned.dmg
1170d3fdb199fbfca2c20b2a77cc81a6fe24b7e4973543a4461e887f14ac68e9 guix-build-d873ff96e51a/output/x86_64-apple-darwin/bitcoin-d873ff96e51a-x86_64-apple-darwin-unsigned.tar.gz
71e93297ed8c581a7ed32a6948ef7b1ea2e7c43cb054181de3b5f604f7a2c28b guix-build-d873ff96e51a/output/x86_64-apple-darwin/bitcoin-d873ff96e51a-x86_64-apple-darwin.tar.gz
46e9b067ec385ee14642aebc5ec09d7d2382e0204eeb17dc64587013eddd5dff guix-build-d873ff96e51a/output/x86_64-linux-gnu/SHA256SUMS.part
23278b19daac51e7df65b817b79fc93562d0f4eb193ef87472456f4bed1464d7 guix-build-d873ff96e51a/output/x86_64-linux-gnu/bitcoin-d873ff96e51a-x86_64-linux-gnu-debug.tar.gz
4d5e5e23f089a59185f62faf367d8ca86476e406e6b7bbc9e8950cd89d94534d guix-build-d873ff96e51a/output/x86_64-linux-gnu/bitcoin-d873ff96e51a-x86_64-linux-gnu.tar.gz
eec8ab97ee9aceef8cb4e7cb5026225ffc5c7b8e8a6d376e8348020000e5af88 guix-build-d873ff96e51a/output/x86_64-w64-mingw32/SHA256SUMS.part
a31819e67c373f30eafce8dbcb3d6d0c61d1dcf59c51023aa79321934f8a7d2a guix-build-d873ff96e51a/output/x86_64-w64-mingw32/bitcoin-d873ff96e51a-win64-debug.zip
2e7d4e533a5998863c115c586c61b75b4039cd329e12ed24cff78b7f16b6ea57 guix-build-d873ff96e51a/output/x86_64-w64-mingw32/bitcoin-d873ff96e51a-win64-setup-unsigned.exe
3dabbd627b532beef57c3d4b5bd30c93c5ea74c492918484cf24685aca8d7bc4 guix-build-d873ff96e51a/output/x86_64-w64-mingw32/bitcoin-d873ff96e51a-win64-unsigned.tar.gz
ec438531b4694913dbbf7c91920dcbd957354b164f807867c16a001898edf669 guix-build-d873ff96e51a/output/x86_64-w64-mingw32/bitcoin-d873ff96e51a-win64.zip
```
ACKs for top commit:
laanwj:
Code review ACK d873ff96e5
MarcoFalke:
re-ACK d873ff96e5 only changes: 📼
Tree-SHA512: fc7d781e8cc0fc0a0080eb4b5019e91c55275e087149ed3b5abc6b691170b0ab76f1dd3ce9bb8846eef023897a89123e14751ce8facf2a170829858199904bff
2224bcabc4 [doc] RBF feerate rule (glozow)
Pull request description:
RBF policy requires the replacement transaction have a higher feerate than each of the directly conflicting transactions (see `PaysMoreThanConflicts`).
It was pointed out that this rule is undocumented: https://github.com/bitcoin/bitcoin/pull/25038#discussion_r889064935
ACKs for top commit:
laanwj:
ACK 2224bcabc4
w0xlt:
ACK 2224bcabc4
darosior:
ACK 2224bcabc4
ariard:
ACK 2224bcab
t-bast:
ACK 2224bcabc4
Tree-SHA512: 0d3915100973b66d115c3294f3037d0c5473c00236c8823a4b2fe12ff172457af56c295b41ac0ef983de030f40f0817c046bb486bf60a5a593d1c4524fe1b9d2
Mostly changes to remove src/univalue exceptions from the various linters,
and the required code changes to make them happy. As well as minor doc
changes.
e47c6c7656 Reset settings.json when GUI options are reset (Ryan Ofsky)
99ccc02b65 Add release notes about unified bitcoin-qt and bitcoind persistent settings (Ryan Ofsky)
504b06b1de Migrate -lang setting from QSettings to settings.json (Ryan Ofsky)
9a016a3c07 Migrate -prune setting from QSettings to settings.json (Ryan Ofsky)
f067e19433 Migrate -proxy and -onion settings from QSettings to settings.json (Ryan Ofsky)
a09e3b7cf2 Migrate -listen and -server settings from QSettings to settings.json (Ryan Ofsky)
d2ada6e635 Migrate -upnp and -natpmp settings from QSettings to settings.json (Ryan Ofsky)
1dc4fc29c1 Migrate -spendzeroconfchange and -signer settings from QSettings to settings.json (Ryan Ofsky)
a7ef6d5975 Migrate -par setting from QSettings to settings.json (Ryan Ofsky)
284f339de6 Migrate -dbcache setting from QSettings to settings.json (Ryan Ofsky)
Pull request description:
If a setting like pruning, port mapping, or a network proxy is enabled in the GUI, it will now be stored in the bitcoin persistent setting file in the datadir and shared with bitcoind, instead of being stored as Qt settings which end up in the the windows registry or platform specific config files and are ignored by bitcoind.
This PR has been split off from bitcoin/bitcoin#15936 so some review of these commits previously took place in that PR.
ACKs for top commit:
furszy:
Code review ACK e47c6c76
hebasto:
ACK e47c6c7656
Tree-SHA512: 076ea7c7efe67805b4a357113bfe1643dce364d0032774106de59566a0ed5771d57a5923920085e03d686beb34b98114bd278555dfdf8bb7af0b778b0f35b7d2
ce893c0497 doc: Update developer notes (Anthony Towns)
d2852917ee sync.h: Imply negative assertions when calling LOCK (Anthony Towns)
bba87c0553 scripted-diff: Convert global Mutexes to GlobalMutexes (Anthony Towns)
a559509a0b sync.h: Add GlobalMutex type (Anthony Towns)
be6aa72f9f qt/clientmodel: thread safety annotation for m_cached_tip_mutex (Anthony Towns)
f24bd45b37 net_processing: thread safety annotation for m_tx_relay_mutex (Anthony Towns)
Pull request description:
This changes `LOCK(mutex)` for non-global, non-recursive mutexes to be annotated with the negative capability for the mutex it refers to, to prevent . clang applies negative capabilities recursively, so this helps avoid forgetting to annotate functions.
This can't reasonably be used for globals, because clang would require every function to be annotated with `EXCLUSIVE_LOCKS_REQUIRED(!g_mutex)` for each global mutex; so this introduces a trivial `GlobalMutex` subclass of `Mutex`, and reduces the annotations for both `GlobalMutex` to `LOCKS_EXCLUDED` which only catches trivial errors (eg (`LOCK(x); LOCK(x);`).
ACKs for top commit:
MarcoFalke:
review ACK ce893c0497🐦
hebasto:
ACK ce893c0497
Tree-SHA512: 5c35e8c7677ce3d994a7e3774f4344adad496223a51b3a1d1d3b5f20684b2e1d5cff688eb3fbc8d33e1b9940dfa76e515f9434e21de6f3ce3c935e29a319f529
that was added in 2015 by commit b8c06ef40 in PR 7003, as that potential issue
would now be caught by the test/lint/lint-format-strings.py script run by the CI
52a797bfe5 doc: Avoid ADL for function calls (Hennadii Stepanov)
Pull request description:
It happened two times recently, when [ADL](https://en.cppreference.com/w/cpp/language/adl) popped up unexpectedly and brought some confusion:
- https://github.com/bitcoin/bitcoin/pull/24338/files#r805989994
> Any idea why this even compiles?
- https://www.erisian.com.au/bitcoin-core-dev/log-2022-02-18.html#l-51:
> 2022-02-18T03:24:14 \<dongcarl\> Does anyone know why this compiles? 6d3d2caa37
> 2022-02-18T03:24:14 \<dongcarl\> GetUTXOStatsWithHasher and MakeUTXOHasher are both in the `kernel::` namespace and I never added a `using` declaration on top...
> 2022-02-18T03:25:53 \<sipa\> https://en.cppreference.com/w/cpp/language/adl ?
Let's document our intention to avoid similar cases in the future.
ACKs for top commit:
laanwj:
Anyhow, ACK 52a797bfe5, there is no need to hold merge up on this, documenting it is a step forward.
Tree-SHA512: f52688b5d8f6130302185206ec6ea4731b099a75294ea2d477901a52d6d58473e3427e658aea408c140c2824c37a0399ec7376aded2a91197895ea52d51f0018
74743ad905 Clarify in release process how to update defaultAssumeValid/nMinimumChainWork (Jon Atack)
415345d547 Release process: use 4096 blocks and getbestblockhash for getchaintxstats (Jon Atack)
fe048f7f7c Specify in release process which chains need to be updated (Jon Atack)
584147682a Reorganize release process chainparams section to reduce repetition (Jon Atack)
e8f844888f Clarify release process overhead note to be more actionable (Jon Atack)
e538eada7c Release process: exclude huge files for mainnet m_assumed_blockchain_size (laanwj)
b4d2d74767 Release process: specify blockchain/chain_state units, reduce repetition (Jon Atack)
318655c395 Add missing references to signet in the release process (Jon Atack)
Pull request description:
Release process updates, fixes and clarifications regarding updating the chainparams:
- add missing references to signet
- specify specify blockchain/chainstate units, reduce repetition
- exclude huge files for m_assumed_blockchain_size on mainnet
- rewrite overhead note to be more actionable
- reorganize the chainparams section to reduce repetition
- specify which chains need to be updated
- use 4096 blocks and getbestblockhash for getchaintxstats
- clarify how to update defaultAssumeValid and nMinimumChainWork
ACKs for top commit:
laanwj:
ACK 74743ad905
brunoerg:
re-ACK 74743ad905
Tree-SHA512: 7fc092be739f63c5d8404add2dcbcd0c570b680ff0ab36a9b5a774b2e930717beebaa6c867ab6db6795b3c234d9016ab1ae905a78d6ea6610140a59930c43029
4185570340 Add RPC to get mempool txs spending outputs (t-bast)
Pull request description:
We add an RPC to fetch mempool transactions spending any of the given outpoints.
Without this RPC, application developers need to first call `getrawmempool` which returns a long list of `txid`, then fetch each of these transactions individually (`getrawtransaction`) to check whether they spend the given outpoints, which wastes a lot of bandwidth (in the worst case we need to transfer the whole mempool).
For example in lightning, when we discover that one of our channel funding transactions has been spent, we need to find the spending transaction to claim our outputs from it. We are currently forced to fetch the whole mempool to do the analysis ourselves, which is quite costly.
I believe that this RPC is also generally useful when doing some introspection on your mempool after one of your transactions failed to broadcast, for example when you implement RBF at the application level. Fetching and analyzing the conflicting transaction gives you more information to successfully replace it.
ACKs for top commit:
darosior:
re-utACK 4185570340
vincenzopalazzo:
re-ACK 4185570340
danielabrozzoni:
re-tACK 4185570340
w0xlt:
reACK 4185570340
Tree-SHA512: 206687efb720308b7e0b6cf16dd0a994006c0b5a290c8eb386917a80130973a6356d0d5cae1c63a01bb29e066dd721594969db106cba7249214fcac90d2c3dbc
If a bitcoind setting like pruning, port mapping, or a network proxy is enabled
in the GUI, it will now be stored in the bitcoin persistent setting file and
shared with bitcoind, instead of being stored as Qt settings backed by the
windows registry or platform specific config files.
bd5dbc30db doc: update developer notes wrt --enable-debug and DEBUG_LOCKCONTENTION (Jon Atack)
345647c4da ci: add DEBUG_LOCKCONTENTION to CI task containing DEBUG_LOCKORDER (Jon Atack)
247d17033f build: add DEBUG_LOCKCONTENTION to --enable-debug configuration (Jon Atack)
Pull request description:
- Add `DEBUG_LOCKCONTENTION` flag to the `--enable-debug` configuration
- Add `DEBUG_LOCKCONTENTION` to the native tsan CI task that contains `DEBUG_LOCKORDER` (verified that the CI has all logging categories enabled by default, except libevent and leveldb)
- Update the developer notes that `--enable-debug` configures `DEBUG_LOCKCONTENTION`
Related to https://github.com/bitcoin/bitcoin/issues/24709.
Top commit has no ACKs.
Tree-SHA512: 8e9c068d9a4841ad1ab08a2bf4ce96d6fee195e458f6802852cba0d71deb9a485059d355ac8bd1fc15410437f19503b77fc425bf53a1d48dc82a43a979daad17
baa3ddc49c doc: add release notes about `getreceivedbylabel` returning an error if the label is not in the address book. (furszy)
8897a21658 rpc: getreceivedbylabel, don't loop over the entire wallet txs map if no destinations were found for the input label. (furszy)
Pull request description:
Built on top of #23662, coming from comment https://github.com/bitcoin/bitcoin/pull/23662#pullrequestreview-971407999.
If `wallet.GetLabelAddresses()` returns an empty vector (the wallet does not have stored destinations with that label in the addressbook) or if none of the returned destinations are from the wallet, we can return the function right away.
Otherwise, we are walking through all the wallet txs + outputs for no reason (`output_scripts` is empty).
ACKs for top commit:
achow101:
ACK baa3ddc49c
theStack:
re-ACK baa3ddc49c
w0xlt:
ACK baa3ddc49c
Tree-SHA512: 00e10365b179bf008da2f3ef8fbb3ee04a330426374020e3f2d0151b16991baba4ef2b944e4659452f3e4d6cb20f128d0918ddf0453933a25a4d9fd8414a1911
Since the Boost.Process usage check was added to the build system
(commit abc057c603), passing the option
`--disable-external-signer` explicitly is not needed anymore on OpenBSD;
The configure script will automatically detect that including
<boost/process.hpp> leads to a compile error and disable external signer
support accordingly.
a01b92ad86 doc: add release notes about removal of the `deprecatedrpc=softforks` flag (Sebastian Falbesoner)
8c5533c7a9 rpc: remove deprecated "softforks" field from getblockchaininfo (Sebastian Falbesoner)
Pull request description:
Information on soft fork status has been moved from the `getblockchaininfo` RPC to the `getdeploymentinfo` RPC in #23508. The "softfork" result in `getblockchaininfo` was still available for 23.0 with the `-deprecatedrpc=softforks` configuration option, but this can be fully removed now for the next release (24.0).
ACKs for top commit:
shaavan:
ACK a01b92ad86
ajtowns:
ACK a01b92ad86
Tree-SHA512: 692d9d02fdf0b3c18376644a85b24b57efebf612738084c01ef47d47e41861e773688613a808e81f10ab6eec340de00eef96987a1e34d612aaf7f0a0b134d89e
eb02713efc doc: add minimum required kernel version to dependencies.md (fanquake)
dcad5f70f1 guix: consolidate kernel headers to 5.15 (fanquake)
Pull request description:
Our minimum supported kernel version is currently defined by Guix, as the version passed to the [`--enable-kernel=`](https://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html) option when configuring glibc. That version is [currently set to 3.2.0](https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/base.scm?id=34e9eae68c9583acce5abc4100add3d88932a5ae#n776):
```scheme
;; This is the default for most architectures as of GNU libc 2.26,
;; but we specify it explicitly for clarity and consistency. See
;; "kernel-features.h" in the GNU libc for details.
"--enable-kernel=3.2.0"
```
and has been that way since we started using Guix (i.e from Guix 1.3.0, with the release v22.0).
Passing `--enable-kernel` defines `__LINUX_KERNEL_VERSION` inside glibc, which is then used to determine supported features & syscall usage. For example, some defines in `unix/sysv/linux/kernel-features.h`, from glibc version 2.24, where glibcs default supported kernel version was still 2.6.32 (it's more modern as of recent releases):
```cpp
#ifndef __LINUX_KERNEL_VERSION
/* We assume the worst; all kernels should be supported. */
# define __LINUX_KERNEL_VERSION0
#endif
/* Support for various CLOEXEC and NONBLOCK flags was added in
2.6.23. */
#define __ASSUME_O_CLOEXEC1
/* prlimit64 is available in 2.6.36. */
#if __LINUX_KERNEL_VERSION >= 0x020624
# define __ASSUME_PRLIMIT641
#endif
```
Note that because we currently specify the `5.15` headers, the exact version being used, i.e 5.15.x, changes when we update our time-machine commit, as Guix updates all it's header packages as new point releases become available. Currently it is [`5.15.28`](https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/linux.scm?id=34e9eae68c9583acce5abc4100add3d88932a5ae#n380). The changelog for the 5.15 headers is available [here](https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.36).
Similar to glibc, it may currently be possible to build and run bitcoind against older kernels, however, for the purposes of documenting what we support for our release binaries, I can't see a reason to document anything other than the version that we are targeting when building the glibc used to build the release binaries.
Guix Build (on x86_64):
```bash
22ff2d3a72d337c4eccbfa4c834a67c7c3397f225aedb71a3c636f2708964e93 guix-build-eb02713efc17/output/aarch64-linux-gnu/SHA256SUMS.part
e316b2d0806183e0e51a25722f48af85d145b1581f44f68b925d9f484a5aa0d3 guix-build-eb02713efc17/output/aarch64-linux-gnu/bitcoin-eb02713efc17-aarch64-linux-gnu-debug.tar.gz
da667d935d9331c5cbca2e0e334cd7e56202ee294553459672fa50f13f501c4d guix-build-eb02713efc17/output/aarch64-linux-gnu/bitcoin-eb02713efc17-aarch64-linux-gnu.tar.gz
f44f2921f3dac2c545806dffb579137fb9eeeee15671395f6a7f817ed6213143 guix-build-eb02713efc17/output/arm-linux-gnueabihf/SHA256SUMS.part
101bab25ab2a6c36729cdf840264a85700cc3cfa23d3900b0bee0ac9ae637e8d guix-build-eb02713efc17/output/arm-linux-gnueabihf/bitcoin-eb02713efc17-arm-linux-gnueabihf-debug.tar.gz
9f7338ee42234949ef3104c6cb2b8a723d616a46d0047d833062adc92e3b6b72 guix-build-eb02713efc17/output/arm-linux-gnueabihf/bitcoin-eb02713efc17-arm-linux-gnueabihf.tar.gz
5ca08e7b38c4dd4456145602f25b015c164c0cd0317dd2a26855dc0495605418 guix-build-eb02713efc17/output/arm64-apple-darwin/SHA256SUMS.part
186c9e2df4034472107964e835ee7a05777c7a0fa5e0db12b5740f18e732d7d5 guix-build-eb02713efc17/output/arm64-apple-darwin/bitcoin-eb02713efc17-arm64-apple-darwin-unsigned.dmg
4e252c7775662777ddcb0a1b0efac6b6e71c25479d6b44b821199ae00abd18ca guix-build-eb02713efc17/output/arm64-apple-darwin/bitcoin-eb02713efc17-arm64-apple-darwin-unsigned.tar.gz
4360342994d54839bbf5fb4d86c6c0b0a3cbcef68b0d2c991aab6e81301638e7 guix-build-eb02713efc17/output/arm64-apple-darwin/bitcoin-eb02713efc17-arm64-apple-darwin.tar.gz
f354822050cd625de7445cfa317475cfad90a7e39d135c5b99950ee69969f445 guix-build-eb02713efc17/output/dist-archive/bitcoin-eb02713efc17.tar.gz
aa864574dd692bb40df95e17c08113f5bcd04b7d5997a2f74ca0557cae3edfcd guix-build-eb02713efc17/output/powerpc64-linux-gnu/SHA256SUMS.part
45df2a4ec5592834fd08d36068cd0968de281870cb9df48cc4783078b85985dd guix-build-eb02713efc17/output/powerpc64-linux-gnu/bitcoin-eb02713efc17-powerpc64-linux-gnu-debug.tar.gz
2bc1c481635ac073d61f51db425576a42a54b16218a00e5f80579426dbf9677b guix-build-eb02713efc17/output/powerpc64-linux-gnu/bitcoin-eb02713efc17-powerpc64-linux-gnu.tar.gz
403d7790e611d3e07b25e02549c9f50e51fff2e1a323605db4f9a569712771a7 guix-build-eb02713efc17/output/powerpc64le-linux-gnu/SHA256SUMS.part
db40032c3b25d95012496f1b3fa5df7f207dcbeefa510bd140b96df4dfd84c88 guix-build-eb02713efc17/output/powerpc64le-linux-gnu/bitcoin-eb02713efc17-powerpc64le-linux-gnu-debug.tar.gz
eea8b4ee96dc8a9813b727550bf07202a6f9cba99605247813beb5251c7f2623 guix-build-eb02713efc17/output/powerpc64le-linux-gnu/bitcoin-eb02713efc17-powerpc64le-linux-gnu.tar.gz
7164e539d25c300b993a620caacdcef659bb6a7c4775a873e30ee645c9ceed15 guix-build-eb02713efc17/output/riscv64-linux-gnu/SHA256SUMS.part
3ae271e6fb94e5d4e46a402508a02d659e879d222c6696e57c78530157eb39ae guix-build-eb02713efc17/output/riscv64-linux-gnu/bitcoin-eb02713efc17-riscv64-linux-gnu-debug.tar.gz
8c37d0b790c28b692804b360605baec4371af4f080c0024ba75f06c0096a4356 guix-build-eb02713efc17/output/riscv64-linux-gnu/bitcoin-eb02713efc17-riscv64-linux-gnu.tar.gz
51bbf04cb32b579ba5609fe3ef24e9901f8d49e3311fe9776ee1fdb644f7e0b1 guix-build-eb02713efc17/output/x86_64-apple-darwin/SHA256SUMS.part
8e81f8badb0cff1aa430a899065cf9744b4b2d45addb8e30606a2f8bf08faa26 guix-build-eb02713efc17/output/x86_64-apple-darwin/bitcoin-eb02713efc17-x86_64-apple-darwin-unsigned.dmg
8b4120b6d83c03dae34b0b5a189522d01c523ab005d816339fdfddf9c412ef15 guix-build-eb02713efc17/output/x86_64-apple-darwin/bitcoin-eb02713efc17-x86_64-apple-darwin-unsigned.tar.gz
26e633faba4f05f51f4e0bffaa2bbbf8c2d5d134d6777c9395bf9b65af6a808c guix-build-eb02713efc17/output/x86_64-apple-darwin/bitcoin-eb02713efc17-x86_64-apple-darwin.tar.gz
16c96d1f349ca3fbf5ffb8e00d5defe1af5a14abb6f61abdbd367e9a5e99bf33 guix-build-eb02713efc17/output/x86_64-linux-gnu/SHA256SUMS.part
faa203c9c3943c2f30ca3f4f30c3eee52e38ac9a2f15c6303b0c8ff0be146e07 guix-build-eb02713efc17/output/x86_64-linux-gnu/bitcoin-eb02713efc17-x86_64-linux-gnu-debug.tar.gz
b5cf5154ac0e2138a4ccbc7639026d909e606b9f55c5859ae54d941eb950759b guix-build-eb02713efc17/output/x86_64-linux-gnu/bitcoin-eb02713efc17-x86_64-linux-gnu.tar.gz
bc14a09399ef3a6d9696116ddda6509b6cb1726719dfd462106cb9d2fde32efc guix-build-eb02713efc17/output/x86_64-w64-mingw32/SHA256SUMS.part
7c0a773f0e892e41fe8f7b299be655e53f110a64bd6e77c2e7a6b4c699605498 guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64-debug.zip
27f6a50394c61c0efa2f3afe655a265c64a34249041ef0090f9043cd4cdc8c71 guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64-setup-unsigned.exe
dd5bb661a9d99bbc2c2c7256996b26bef116b2e61b7497ada26b3322550d53cb guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64-unsigned.tar.gz
84d5068dd59180498473263d757192a422859c0704a2e45a762d1635e49efb80 guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64.zip
```
Guix build (on arm64):
```bash
2bbcf455381d4be6bb402c705dba5655de3e1b62a0ed1dbbfcb573450a63d148 guix-build-eb02713efc17/output/arm-linux-gnueabihf/SHA256SUMS.part
c9d982eb6c9efc752fffb3a1d2b14e8cc4d9e2cf4c03c2f02eb320d04f52a86d guix-build-eb02713efc17/output/arm-linux-gnueabihf/bitcoin-eb02713efc17-arm-linux-gnueabihf-debug.tar.gz
0c0b3122dcdc051bee1022dc9b0cf7771b7f6b30fa3e7369c97907d8c10d7ea3 guix-build-eb02713efc17/output/arm-linux-gnueabihf/bitcoin-eb02713efc17-arm-linux-gnueabihf.tar.gz
5388f8a7525ed49d11569988e598a0ec68ddcaf9b35cff0c8bcb02187b0fbaad guix-build-eb02713efc17/output/arm64-apple-darwin/SHA256SUMS.part
16b745e2b2e036d65b549be740116d9b6e819730cc76075f01bdbc4beb166724 guix-build-eb02713efc17/output/arm64-apple-darwin/bitcoin-eb02713efc17-arm64-apple-darwin-unsigned.dmg
18eaede02d12dcbb83003272b5b79a08a10067a326542687ab445bfc623ce9e8 guix-build-eb02713efc17/output/arm64-apple-darwin/bitcoin-eb02713efc17-arm64-apple-darwin-unsigned.tar.gz
5fb73968c7ea50c9642d3cddcd745a512be3043ada314b8a1fc94f179744a1d8 guix-build-eb02713efc17/output/arm64-apple-darwin/bitcoin-eb02713efc17-arm64-apple-darwin.tar.gz
f354822050cd625de7445cfa317475cfad90a7e39d135c5b99950ee69969f445 guix-build-eb02713efc17/output/dist-archive/bitcoin-eb02713efc17.tar.gz
fad672b9e5d372ba5511c14ed48ef77bcf303d475f35680bd4a668fee150225a guix-build-eb02713efc17/output/powerpc64-linux-gnu/SHA256SUMS.part
246aa854e87675a0b90cc14f7b6affcfefabfc0f79edd3dc96ae6b98010b8b1c guix-build-eb02713efc17/output/powerpc64-linux-gnu/bitcoin-eb02713efc17-powerpc64-linux-gnu-debug.tar.gz
90e968e0bab84e80a9f2fe9498eea7c59d8908f5a16accd93d7f9318a7098ce0 guix-build-eb02713efc17/output/powerpc64-linux-gnu/bitcoin-eb02713efc17-powerpc64-linux-gnu.tar.gz
65f0c018d882d7fc845a9bb1581824b17e7ecf0df7081ab2538f0e617e120a8b guix-build-eb02713efc17/output/powerpc64le-linux-gnu/SHA256SUMS.part
0bf7fcd127180e5e04112914747496db535226bf05126690f259fa0cf2a96642 guix-build-eb02713efc17/output/powerpc64le-linux-gnu/bitcoin-eb02713efc17-powerpc64le-linux-gnu-debug.tar.gz
14fc3e17dfa903f83e44f970c8b4e4726e7476c59d0fffdec815a1c80ec1b51a guix-build-eb02713efc17/output/powerpc64le-linux-gnu/bitcoin-eb02713efc17-powerpc64le-linux-gnu.tar.gz
9018f95b54d0643d734260b6eb69ee5f086c98e62f25dd579675b467a844793d guix-build-eb02713efc17/output/riscv64-linux-gnu/SHA256SUMS.part
e1f2b3678c22103d7b89cbbeec9b2863c9c6f749ff4cbedd74cb6e62598c0a04 guix-build-eb02713efc17/output/riscv64-linux-gnu/bitcoin-eb02713efc17-riscv64-linux-gnu-debug.tar.gz
bf9fa35119344dfc93048196dd9cd5bb230b0785350ae5150bb4bdb28fd8423d guix-build-eb02713efc17/output/riscv64-linux-gnu/bitcoin-eb02713efc17-riscv64-linux-gnu.tar.gz
51bbf04cb32b579ba5609fe3ef24e9901f8d49e3311fe9776ee1fdb644f7e0b1 guix-build-eb02713efc17/output/x86_64-apple-darwin/SHA256SUMS.part
8e81f8badb0cff1aa430a899065cf9744b4b2d45addb8e30606a2f8bf08faa26 guix-build-eb02713efc17/output/x86_64-apple-darwin/bitcoin-eb02713efc17-x86_64-apple-darwin-unsigned.dmg
8b4120b6d83c03dae34b0b5a189522d01c523ab005d816339fdfddf9c412ef15 guix-build-eb02713efc17/output/x86_64-apple-darwin/bitcoin-eb02713efc17-x86_64-apple-darwin-unsigned.tar.gz
26e633faba4f05f51f4e0bffaa2bbbf8c2d5d134d6777c9395bf9b65af6a808c guix-build-eb02713efc17/output/x86_64-apple-darwin/bitcoin-eb02713efc17-x86_64-apple-darwin.tar.gz
6e5828e2efa4e951b147b8de42f79dee1652933e04c50093bd31ee375c0c4ca9 guix-build-eb02713efc17/output/x86_64-linux-gnu/SHA256SUMS.part
3d3af1d078eee6f66aac2af891fd7d7a77abc3d7164a807d0a7cc44f15e52b9d guix-build-eb02713efc17/output/x86_64-linux-gnu/bitcoin-eb02713efc17-x86_64-linux-gnu-debug.tar.gz
13f452bc65194de16fa91ed87be9790ed0d1a178deefb102fa54d3f9832b8c25 guix-build-eb02713efc17/output/x86_64-linux-gnu/bitcoin-eb02713efc17-x86_64-linux-gnu.tar.gz
1673b5fca6687ea0f196a5f2ce2b79662b3efe01b71f341fc596069a1ade610c guix-build-eb02713efc17/output/x86_64-w64-mingw32/SHA256SUMS.part
d6228bdfb4fbc7b895ed4f0c30e1343c3392bd6e8e5ed33a973887ba0bb749ba guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64-debug.zip
27f6a50394c61c0efa2f3afe655a265c64a34249041ef0090f9043cd4cdc8c71 guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64-setup-unsigned.exe
dd5bb661a9d99bbc2c2c7256996b26bef116b2e61b7497ada26b3322550d53cb guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64-unsigned.tar.gz
50a68d3644dbe5cb5de21993cd0e8992ab9c6aa88c009a75e5d5a55180476ea6 guix-build-eb02713efc17/output/x86_64-w64-mingw32/bitcoin-eb02713efc17-win64.zip
```
ACKs for top commit:
laanwj:
ACK eb02713efc
dongcarl:
Code Review ACK eb02713efc
vincenzopalazzo:
ACK eb02713efc
Tree-SHA512: afee459d881d3231b72711b0beec5410d6b37deb0d94aa0aaca13010f54bf95fadaf7e5081ea8b9c6975a9e2b8be48b761e3b6ce284c06f82be2210db1156e96
We add an RPC to fetch the mempool transactions spending given outpoints.
Without this RPC, application developers would need to first call
`getrawmempool` which returns a long list of `txid`, then fetch each of
these txs individually to check whether they spend the given outpoint(s).
This RPC can later be enriched to also find confirmed transactions instead
of being restricted to mempool transactions.
This matches the version of the kernel targeted when we build the glibcs
we use for release builds in Guix. Other versions / scenerios may
work, but for documentation purposes, this is the version that makes
sense to document, and something we can claim to officially support.
ab5af9ca72 test: Add test for coinselection tracepoints (Andrew Chow)
ca02b68e8a doc: document coin selection tracepoints (Andrew Chow)
8e3f39e4fa wallet: Add some tracepoints for coin selection (Andrew Chow)
15b58383d0 wallet: compute waste for SelectionResults of preset inputs (Andrew Chow)
912f1ed181 wallet: track which coin selection algorithm produced a SelectionResult (Andrew Chow)
Pull request description:
Tracepoints can be useful for coin selection as they would allow us to observe what is being selected, selection parameters, and calculation results. So this PR adds 4 new tracepoints:
1. After `SelectCoins` returns in order to observe the `SelectionResult`
2. After the first `CreateTransactionInternal` to observe the created transaction
3. Prior to the second `CreateTransactionInternal` to notify that the optimistic avoid partial spends selection is occurring
4. After the second `CreateTransactionInternal` to observe the created transaction and inform which solution is being used.
This PR also adds an algorithm enum to `SelectionResult` so that the first tracepoint will be able to report which algorithm was used to produce that result.
The primary use case for these tracepoints is in running coin selection simulations. The script I use to run these simulations use these tracepoints in order to gather data on the algorithm used and the calculated waste.
ACKs for top commit:
jb55:
crACK ab5af9ca72
josibake:
crACK ab5af9ca72
0xB10C:
ACK ab5af9ca72. Code reviewed, ran the `interface_usdt_coinselection.py` test, and tested with the above bpftrace script (updated `%d` -> `%ld` where necessary, ty achow101).
Tree-SHA512: a4bf7a910cdf464622f2f3b5d44c15b891f24852df6e7f8c5b177fe3d8aaa4a1164593a24c3960eb22b16544fa7140e5c745345367b9e291b78395084c0ac8ff
bef61496ab test: compare `/mempool/contents` response with `getrawmempool` RPC (brunoerg)
5bc5cbaf31 doc: add reference to `getrawmempool` RPC in `/mempool/contents` REST doc (brunoerg)
Pull request description:
This PR is similar to #24797, it compares `/mempool/contents` REST response with `getrawmempool` RPC (verbose=True) since they use the same `MempoolToJSON` function.
Also, adds a reference to `getrawmempool` RPC help to get details about the fields from `/mempool/contents`.
ACKs for top commit:
0xB10C:
ACK bef6149
Tree-SHA512: b7e9e9c765ee837986ba167b9234a9b95c9ef0a9ebcc2a03d50f6be6d3aba1480bd77c78111d95df1e4023cde6dfc64bf1e7908d9e5b6f96ca46b76611a4a9b4
abcb8769bf doc: add more info to dependencies.md (Pavol Rusnak)
Pull request description:
Follow-up to https://github.com/bitcoin/bitcoin/pull/23565
I added more info to dependencies.md - especially links to `depends/packages/*.mk` files and link to PRs where used versions were bumped.
Preview at: https://github.com/prusnak/bitcoin/blob/dependencies/doc/dependencies.md
ACKs for top commit:
fanquake:
ACK abcb8769bf - I didn't click on or test all of the links, but this looks ok.
Tree-SHA512: e91deb639afebeb37f7bf05dddad8f70547b51688e938a30692e59dbd7c9e49d52b7f9bfacb74ef60c98862b6f8f444199d0ae06973c42dc647314bc1ffc22d5
1d95b5c783 doc: cleanups to mempool rest endpoints (brunoerg)
b941dec0a9 docs: update `/rest/chaininfo` doc referring to RPC help (brunoerg)
Pull request description:
Internally, `/rest/chaininfo` gets the infos from `getblockchaininfo` and I just realized the documentation of it in `REST-interface.md` is outdated compared to the `getblockchaininfo` RPC one. This PR removes the documentation of the fields and adds a reference to the RPC help.
ACKs for top commit:
jonatack:
ACK 1d95b5c783
Tree-SHA512: 643db202e13e8372105460b0871facb11586dc0ff5e86ec9e105a178bcfeefa3555bb047cd28cfaeb3e747f5a2055e27961813c9e299ba7b2d36151e81049507
4394733331 Add DEBUG_LOCKCONTENTION documentation to the developer notes (Jon Atack)
39a34b6877 Put lock logging behind DEBUG_LOCKCONTENTION preprocessor directive (Jon Atack)
Pull request description:
This is a more minimal, no-frills version of #24734 for backport. The other fixes and improvements in that pull can be done after.
*Copy of the PR 24734 description:*
PRs #22736, #22904 and #23223 changed lock contention logging from a `DEBUG_LOCKCONTENTION` compile-time preprocessor directive to a runtime `lock` log category and improved the logging output. This changed the locking from using `lock()` to `try_lock()`:
- `void Mutex::UniqueLock::lock()` acquires the mutex and blocks until it gains access to it
- `bool Mutex::UniqueLock::try_lock()` doesn't block but instead immediately returns whether it acquired the mutex; it may be used by `lock()` internally as part of the deadlock-avoidance algorithm
In theory the cost of `try_lock` might be essentially the [same](https://www.erisian.com.au/bitcoin-core-dev/log-2022-03-31.html#l-697) relative to `lock`. The test-and-set logic of these calls is purported to be ~ constant time, optimised and light/quick if used carefully (i.e. no mutex convoying), compared to system calls, memory/cache coherency and fences, wait queues, and (particularly) lock contentions. See the discussion around https://github.com/bitcoin/bitcoin/pull/22736#issuecomment-902851054 and after with respect to performance/cost aspects. However, there are reasonable concerns (see [here](https://github.com/bitcoin/bitcoin/pull/22736#discussion_r691277896) and [here](https://www.erisian.com.au/bitcoin-core-dev/log-2022-03-31.html#l-620)) that `Base::try_lock()` may be potentially [costly](https://www.erisian.com.au/bitcoin-core-dev/log-2022-03-31.html#l-700) or [risky](https://github.com/bitcoin/bitcoin/pull/22904#issuecomment-930484001) compared to `Base::lock()` in this very frequently called code.
One alternative to keep the run-time lock logging would be to gate the `try_lock` call behind the logging conditional, for example as proposed in ccd73de1dd and ACKed [here](https://github.com/bitcoin/bitcoin/pull/22736#issuecomment-901980815). However, this would add the [cost](https://github.com/bitcoin/bitcoin/pull/22736#issuecomment-910102353) of `if (LogAcceptCategory(BCLog::LOCK))` to the hotspot, instead of replacing `lock` with `try_lock`, for the most frequent happy path (non-contention).
It turns out we can keep the advantages of the runtime lock contention logging (the ability to turn it on/off at runtime) while out of prudence putting the `try_lock()` call and `lock` logging category behind a `DEBUG_LOCKCONTENTION` compile-time preprocessor directive, and also still retain the lock logging enhancements of the mentioned PRs, as suggested in https://github.com/bitcoin/bitcoin/pull/24734#issuecomment-1085785480 by W. J. van der Laan, in https://github.com/bitcoin/bitcoin/pull/22736#discussion_r691280693, and in the linked IRC discussion.
Proposed here and for backport to v23.
ACKs for top commit:
laanwj:
Code review ACK 4394733331
Tree-SHA512: 89b1271cae1dca0eb251914b1a60fc5b68320aab4a3939c57eec3a33a3c8f01688f05d95dfc31f91d71a6ed80cfe2d67b77ff14742611cc206175e47b2e5d3b1
a2b56dcd1f doc: update OpenBSD build docs for 7.0 (fanquake)
Pull request description:
Removes redundant notes for setting `CC` &`CXX` now that Clang is well and truly the base compiler. See: https://www.openbsd.org/70.html
> Disabled base-gcc on amd64.
Cleans up the wallet docs, i.e #23446.
Make the notes more similar to the FreeBSD notes.
ACKs for top commit:
shaavan:
ACK a2b56dcd1f
theStack:
ACK a2b56dcd1f
Tree-SHA512: a0494de3b168e5c35f541edf62dcb42529b23387febbe4c004eb82ef9aff6f97def43b6cd5c91e13612c5247767d79553efcd21b9792ccb6a9608302c5d082f1
54b39cfb34 Add release notes (stickies-v)
f959fc0397 Update /<count>/ endpoints to use a '?count=' query parameter instead (stickies-v)
a09497614e Add GetQueryParameter helper function (stickies-v)
fff771ee86 Handle query string when parsing data format (stickies-v)
c1aad1b3b9 scripted-diff: rename RetFormat to RESTResponseFormat (stickies-v)
9f1c54787c Refactoring: move declarations to rest.h (stickies-v)
Pull request description:
In RESTful APIs, [typically](https://rapidapi.com/blog/api-glossary/parameters/query/) path parameters (e.g. `/some/unique/resource/`) are used to represent resources, and query parameters (e.g. `?sort=asc`) are used to control how these resources are being loaded through e.g. sorting, pagination, filtering, ...
As first [discussed in #17631](https://github.com/bitcoin/bitcoin/pull/17631#discussion_r733031180), the [current REST api](https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md) contains two endpoints `/headers/` and `/blockfilterheaders/` that rather unexpectedly use path parameters to control how many (filter) headers are returned in the response. While this is no critical issue, it is unintuitive and we are still early enough to easily phase this behaviour out and ensure new endpoints (if any) do not have to stick to non-standard behaviour just for internal consistency.
In this PR, a new `HTTPRequest::GetQueryParameter` method is introduced to easily parse query parameters, as well as two new `/headers/` and `/blockfilterheaders/` endpoints that use a count query parameter are introduced. The old path parameter-based endpoints are kept without too much overhead, but the documentation now points to the new query parameter-based endpoints as the default interface to encourage standardness.
## Behaviour change
### New endpoints and default values
`/headers/` and `/blockfilterheaders/` now have 2 new endpoints that contain query parameters (`?count=<count>`) instead of path parameters (`/<count>/`), as described in REST-interface.md. Since query parameters can easily have default values, I have set this at 5 for both endpoints.
**headers**
`GET /rest/headers/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>`
should now be used instead of
`GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json>`
**blockfilterheaders**
`GET /rest/blockfilterheaders/<FILTERTYPE>/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>`
should now be used instead of
`GET /rest/blockfilterheaders/<FILTERTYPE>/<COUNT>/<BLOCK-HASH>.<bin|hex|json>`
### Some previously invalid API calls are now valid
API calls that contained query strings in the URI could not be parsed prior to this PR. This PR changes behaviour in that previously invalid calls (e.g. `GET /rest/headers/5/somehash.json?someunusedparam=foo`) would now become valid, as the query parameters are properly parsed, and discarded if unused.
For example, prior to this PR, adding an irrelevant `someparam` parameter would be illegal:
```
GET /rest/headers/5/0000004c6aad0c89c1c060e8e116dcd849e0554935cd78ff9c6a398abeac6eda.json?someparam=true
->
Invalid hash: 0000004c6aad0c89c1c060e8e116dcd849e0554935cd78ff9c6a398abeac6eda.json?someparam=true
```
**This behaviour change affects all rest endpoints, not just the 2 new ones introduced here.**
*(Note: I'd be open to implementing additional logic to refuse requests containing unrecognized query parameters to minimize behaviour change, but for the endpoints that we currently have I don't really see the point for that added complexity. E.g. I don't see any scenarios where misspelling a parameter could lead to harmful outcomes)*
## Using the REST API
To run the API HTTP server, start a bitcoind instance with the `-rest` flag enabled. To use the
`blockfilterheaders` endpoint, you'll also need to set `-blockfilterindex=1`:
```
./bitcoind -signet -rest -blockfilterindex=1
```
As soon as bitcoind is fully up and running, you should be able to query the API, for example by
using curl on the command line: ```curl "127.0.0.1:38332/rest/chaininfo.json"```.
To more easily parse the JSON output, you can also use tools like 'jq' or `json_pp`, e.g.:
```
curl -s "localhost:38332/rest/blockfilterheaders/basic/0000004c6aad0c89c1c060e8e116dcd849e0554935cd78ff9c6a398abeac6eda.json?count=2" | json_pp .
```
## To do
- [x] update `doc/release-notes`
## Feedback
This is my first PR (hooray!). Please don't hold back on any feedback/comments/nits/... you may have, big or small, whether they are code, process, language, ... related. I welcome private messages too if there's anything you don't want to clutter the PR with. I'm here to learn and am grateful for everyone's input.
ACKs for top commit:
stickies-v:
I've had to push a tiny doc update to `REST-interface.md` (`git range-diff 219d728 9aac438 54b39cf`) since this was not merged for v23, but since there are no significant changes beyond theStack and jnewbery's ACKs I think this PR is now ready to be considered for merging? @MarcoFalke
jnewbery:
ACK 54b39cfb34
theStack:
re-ACK 54b39cfb34
Tree-SHA512: 3b393ffde34f25605ca12c0b1300799a19684b816a1d03aed38b0f5439df47bfe6a589ffbcd7b83fd2def6c9d00a1bae5e45b1d18df4ae998c617c709990f83f
In most RESTful APIs, path parameters are used to represent resources, and
query parameters are used to control how these resources are being filtered/sorted/...
The old /<count>/ functionality is kept alive to maintain backwards compatibility,
but new paths with query parameters are introduced and documented as the default
interface so future API methods don't break consistency by using query parameters.
6a02355ae9 Add and improve informational links in doc/cjdns.md (Jon Atack)
19538dd41e Add concrete steps in doc/cjdns.md to easily find a friend (Jon Atack)
Pull request description:
and improve the informational links. CJDNS functions with a friend-of-a-friend topology and a key hurdle to getting started is to find a public peer and set up an outbound connection to it. This update makes doing it much easier for people getting started.
Credit to Vasil Dimov for an [IRC suggestion in October 2021](https://www.erisian.com.au/bitcoin-core-dev/log-2021-10-04.html#l-469) and to stickies-v for IRC discussions this week and the [testing guide](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Candidate-Testing-Guide) that led me to redo these steps, provide feedback at https://github.com/bitcoin/bitcoin/issues/24706 and refine the added documentation here.
ACKs for top commit:
dunxen:
ACK 6a02355
stickies-v:
re-ACK [6a02355](6a02355ae9) even though I wasn't opposed to the "friend" terminology since it's the language CJDNS seems to use to denominate the peers you connect to directly in general. Not worth bikeshedding over though.
lsilva01:
Strong ACK 6a02355
Tree-SHA512: b2fa2a200a6a55a709486f7ed2d3830cabffbbffa61a0d211fcb666a918b5754d4e99a58c32909fe58540598066e6ff67bf2fa2fcd56b1b5dcff3c2162f6d962
fa4943e8df doc: Add template for empty release notes (MarcoFalke)
Pull request description:
* Move release process notes from the release notes to the release process documentation
* Clarify that wallet RPC or Settings related release notes snippets should not be duplicated. I think it should be sufficient to only mention them in the wallet section and leave them out from the general RPC section.
* Create an empty template to ensure the release notes can be cleared with a single `cp` command. Also, this ensures that the "no duplication" note isn't deleted again. (We used to have it in at least the 22.0 and 21.0 release notes: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.21.0.md#updated-settings , but it was lost in the 23.0 notes)
ACKs for top commit:
laanwj:
ACK fa4943e8df
Tree-SHA512: 808e100ee1e371f7746a479ddfb237c6895935cffefc0e49033505492a03288013d5c20386af30f2a7dca8ad0c0628bdb6673dcb5cc4fcf4d0183b0ec65ce941
7f6042849c build, qt: use one patch per line in depends/packages/qt.mk (Pavol Rusnak)
826cbc470f build, qt: drop fix_no_printer.patch (Hennadii Stepanov)
ef20add4c9 build, qt: bump Qt5 version to 5.15.3 (Pavol Rusnak)
Pull request description:
build, qt: bump Qt5 version to 5.15.3
Qt 5.15.3 release is a patch release made on the top of Qt 5.15.2. As a patch
release, Qt 5.15.3 does not add any new functionality but provides bug fixes
and other improvements.
https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.3/release-note.md
* dropped patches:
- patches/qt/dont_use_avx_android_x86_64.patch
- patches/qt/fix_bigsur_style.patch
* adjusted patches:
- patches/qt/fix_android_jni_static.patch
- patches/qt/fix_limits_header.patch
- patches/qt/use_android_ndk23.patch
ACKs for top commit:
hebasto:
ACK 7f6042849c
fanquake:
ACK 7f6042849c
Tree-SHA512: dd79475901bc9636fb0ce2424f63ddfe8ab5f85f7f35ac64b0e8708042793c19663be1abdcaef6be95e30bae8aa9e6da4389d768de5c102ded8ab61b3d02b07b
Qt 5.15.3 release is a patch release made on the top of Qt 5.15.2. As a patch
release, Qt 5.15.3 does not add any new functionality but provides bug fixes
and other improvements.
https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.3/release-note.md
* dropped patches:
- patches/qt/dont_use_avx_android_x86_64.patch
- patches/qt/fix_bigsur_style.patch
* adjusted patches:
- patches/qt/fix_android_jni_static.patch
- patches/qt/fix_limits_header.patch
- patches/qt/use_android_ndk23.patch
Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
Describing an optional sub-path as <checkmempool> in the synopsis could
be misleading as the angle brackets normally indicate that the field has
to be replaced a custom value. Clarify that by showing two variants
instead, similar to the block endpoint with the notxdetails option.
Further improvements:
- uppercase <TXID> and <N>, to match the description of the other endpoints
- s/getutxo command/getutxos endpoint/
- describe what the checkmempool option does
- s/serialisation/serialization/ (the US spelling is more dominant than
the UK spelling in the project, and there is indeed no other instance
of the string "serialis*" in the source tree, except once in a release
note)
- link to BIP64 within the text instead of only showing bare URL
- mention that BIP64 is only relevant for bin and hex output formats
- show two endpoint formats of the block section as list
bb84b7145b add tests for no recipient and using send_max while inputs are specified (ishaanam)
49090ec402 Add sendall RPC née sweep (Murch)
902793c777 Extract FinishTransaction from send() (Murch)
6d2208a3f6 Extract interpretation of fee estimation arguments (Murch)
a31d75e5fb Elaborate error messages for outdated options (Murch)
35ed094e4b Extract prevention of outdated option names (Murch)
Pull request description:
Add sendall RPC née sweep
_Motivation_
Currently, the wallet uses a fSubtractFeeAmount (SFFO) flag on the
recipients objects for all forms of sending calls. According to the
commit discussion, this flag was chiefly introduced to permit sweeping
without manually calculating the fees of transactions. However, the flag
leads to unintuitive behavior and makes it more complicated to test
many wallet RPCs exhaustively. We proposed to introduce a dedicated
`sendall` RPC with the intention to cover this functionality.
Since the proposal, it was discovered in further discussion that our
proposed `sendall` rpc and SFFO have subtly different scopes of
operation.
• sendall:
Use _given UTXOs_ to pay a destination the remainder after fees.
• SFFO:
Use a _given budget_ to pay an address the remainder after fees.
While `sendall` will simplify cases of spending a given set of
UTXOs such as paying the value from one or more specific UTXOs, emptying
a wallet, or burning dust, we realized that there are some cases in
which SFFO is used to pay other parties from a limited budget,
which can often lead to the creation of change outputs. This cannot be
easily replicated using `sendall` as it would require manual
computation of the appropriate change amount.
As such, sendall cannot replace all uses of SFFO, but it still has a
different use case and will aid in simplifying some wallet calls and
numerous wallet tests.
_Sendall call details_
The proposed sendall call builds a transaction from a specific
subset of the wallet's UTXO pool (by default all of them) and assigns
the funds to one or more receivers. Receivers can either be specified
with a given amount or receive an equal share of the remaining
unassigned funds. At least one recipient must be provided without
assigned amount to collect the remainder. The `sendall` call will
never create change. The call has a `send_max` option that changes the
default behavior of spending all UTXOs ("no UTXO left behind"), to
maximizing the output amount of the transaction by skipping uneconomic
UTXOs. The `send_max` option is incompatible with providing a specific
set of inputs.
---
Edit: Replaced OP with latest commit message to reflect my updated motivation of the proposal.
ACKs for top commit:
achow101:
re-ACK bb84b7145b
Tree-SHA512: 20aaf75d268cb4b144f5d6437d33ec7b5f989256b3daeeb768ae1e7f39dc6b962af8223c5cb42ecc72dc38cecd921c53c077bc0ec300b994e902412213dd2cc3
_Motivation_
Currently, the wallet uses a fSubtractFeeAmount (SFFO) flag on the
recipients objects for all forms of sending calls. According to the
commit discussion, this flag was chiefly introduced to permit sweeping
without manually calculating the fees of transactions. However, the flag
leads to unintuitive behavior and makes it more complicated to test
many wallet RPCs exhaustively. We proposed to introduce a dedicated
`sendall` RPC with the intention to cover this functionality.
Since the proposal, it was discovered in further discussion that our
proposed `sendall` rpc and SFFO have subtly different scopes of
operation.
• sendall:
Use _specific UTXOs_ to pay a destination the remainder after fees.
• SFFO:
Use a _specific budget_ to pay an address the remainder after fees.
While `sendall` will simplify cases of spending from specific UTXOs,
emptying a wallet, or burning dust, we realized that there are some
cases in which SFFO is used to pay other parties from a limited budget,
which can often lead to the creation of change outputs. This cannot be
easily replicated using `sendall` as it would require manual computation
of the appropriate change amount.
As such, sendall cannot replace all uses of SFFO, but it still has a
different use case and will aid in simplifying some wallet calls and
numerous wallet tests.
_Sendall call details_
The proposed sendall call builds a transaction from a specific subset of
the wallet's UTXO pool (by default all of them) and assigns the funds to
one or more receivers. Receivers can either be specified with a specific
amount or receive an equal share of the remaining unassigned funds. At
least one recipient must be provided without assigned amount to collect
the remainder. The `sendall` call will never create change. The call has
a `send_max` option that changes the default behavior of spending all
UTXOs ("no UTXO left behind"), to maximizing the output amount of the
transaction by skipping uneconomic UTXOs. The `send_max` option is
incompatible with providing a specific set of inputs.
Removes redundant notes for setting CC & CXX now that Clang is well and
truly the base compiler.
Cleans up the wallet docs, i.e #23446.
Make the notes more similar to FreeBSD.
7e22d80af3 addrman: fix incorrect named args (fanquake)
67f654ef61 doc: Document clang-tidy in dev notes (MarcoFalke)
Pull request description:
The documentation, and a single commit extracted from #24661.
Motivation:
> Incorrect named args are source of bugs, like https://github.com/bitcoin/bitcoin/pull/22979.
> To allow them being checked by clang-tidy, use a format it can understand.
ACKs for top commit:
glozow:
ACK 7e22d80af3
Tree-SHA512: 4037fcea59fdf583b171bce7ad350299fe5f9feb3c398413432168f3b9a185e51884d5b30e4b4ab9c6c5bb896c178cfaee1d78d5b4f0034cd70121c9ea4184b7
b5ba3b5b2c doc: mention that BDB is for the legacy wallet in build-freebsd.md (fanquake)
Pull request description:
Re-order legacy and descriptor wallet section.
Remove prelude that pointlessly repeats the same info.
Cleanup configure examples.
FreeBSD version of https://github.com/bitcoin/bitcoin/pull/23446.
ACKs for top commit:
shaavan:
ACK b5ba3b5b2c
Tree-SHA512: ed85acee5c1b933b57d038d144768da1c4b1f1cfd441d9191353b82d50af16adb10aabb3b4661dc9aee54405ab3af2b800e39f9973261a041b2cf0db8675b5c4
f44efc3e2c doc: update i2p.md with cjdns, improve local addresses section (Jon Atack)
3bf6f0cf2c doc: update tor.md with cjdns and getnodeaddresses, fix tor grep, (Jon Atack)
ed15848475 doc: create initial doc/cjdns.md for cjdns how-to documentation (Jon Atack)
Pull request description:
and update and improve doc/tor.md and doc/i2p.md.
Adapted in part from the CJDNS description in https://github.com/bitcoin/bitcoin/pull/23077 and feedback by Vasil Dimov and from the CJDNS documentation and feedback by Caleb James DeLisle.
Targets backport to v23.x.
Co-authored-by: Vasil Dimov <vd@FreeBSD.org>
ACKs for top commit:
vasild:
ACK f44efc3e2c
lsilva01:
ACK f44efc3
Tree-SHA512: 7b7c69f76bc8a5705d324892f32bfe0eb21bcf048054748053eca167c65a2121f6332f40ac6ff98c955e6e8b53233c74c365d887c364ef1d5944f1c49675a6b4
