fa84df1f03 scripted-diff: wallet: rename AvailableCoinsParams members to snake_case (furszy)
61c2265629 wallet: group AvailableCoins filtering parameters in a single struct (furszy)
f0f6a3577b RPC: listunspent, add "include immature coinbase" flag (furszy)
Pull request description:
Simple PR; adds a "include_immature_coinbase" flag to `listunspent` to include the immature coinbase UTXOs on the response. Requested by #25728.
ACKs for top commit:
danielabrozzoni:
reACK fa84df1f03
achow101:
ACK fa84df1f03
aureleoules:
reACK fa84df1f03
kouloumos:
reACK fa84df1f03
theStack:
Code-review ACK fa84df1f03
Tree-SHA512: 0f3544cb8cfd0378a5c74594480f78e9e919c6cfb73a83e0f3112f8a0132a9147cf846f999eab522cea9ef5bd3ffd60690ea2ca367dde457b0554d7f38aec792
It's nice to be able to use named options and positional arguments together.
Most shell tools accept both, and python functions combine options and
arguments allowing them to be passed with even more flexibility. This change
adds support for python's approach so as a motivating example:
bitcoin-cli -named createwallet wallet_name=mywallet load_on_startup=1
Can be shortened to:
bitcoin-cli -named createwallet mywallet load_on_startup=1
JSON-RPC standard doesn't have a convention for passing named and positional
parameters together, so this implementation makes one up and interprets any
unused "args" named parameter as a positional parameter array.
1184a66347 doc: Rearrange some lines in the dependency graph of libraries (Stacie Waleyko)
Pull request description:
In this PR, I've attempted to improve readability in the [dependency graph of libraries](https://github.com/bitcoin/bitcoin/blob/master/doc/design/libraries.md) by untangling a few crossed lines. I'm not sure if this is that big of an improvement but wanted to throw it out there.
I used an extremely scientific method of manually counting the number of crossed lines in the original diagram and got 15. This PR reduces that number down to about 10.
I also changed the curve of the lines to "basis" which rounds the edges out. Again, not sure if it really is that much of an improvement, but it seems marginally easier on the eyes.
Here is what the new graph looks like rendered:
The changes can be verified independently with [Mermaid](https://mermaid-js.github.io/mermaid/#/), with the easiest way being the online editor: https://mermaid.live/
I did try moving some more stuff around, particularly the top level of library callers, but was not able to simplify the graph any further.
ACKs for top commit:
shaavan:
ACK 1184a66347
Tree-SHA512: 61d33d68c1e6fa354aebdda5e06e9c7a722ca20886c6acc30dd08af7133d737130d7a646d87f9e5a8ae0bc5a5aabfbc64ded9ee04dfeed8f23d948444add916b
a8250e30f1 doc: add release note about `/rest/deploymentinfo` (brunoerg)
5c96020024 doc: add `/deploymentinfo` in REST-interface (brunoerg)
3e44bee08e test: add coverage for `/rest/deploymentinfo` (brunoerg)
91497031cb rest: add `/deploymentinfo` (brunoerg)
Pull request description:
#23508 added a new RPC named `getdeploymentinfo`, it moved the softfork section from `getblockchaininfo` into this new one. In the REST interface, we have an endpoint named`/rest/chaininfo.json` (which refers to `getblockchaininfo`), so, this PR adds a new REST endpoint named `/deploymentinfo` which refers to `getdeploymentinfo`.
You can use it by passing a block hash, e.g: '/rest/deploymentinfo/<BLOCKHASH>.json' or you can use it without passing a block hash to get the 'deploymentinfo' for the last block.
ACKs for top commit:
jonatack:
re-ACK a8250e30f1 rebase-only since my last review at c65f82bb
achow101:
ACK a8250e30f1
stickies-v:
re-ACK a8250e30f1
Tree-SHA512: 0735183b6828d51a72ed0e2be5a09b314ac4693f548982c6e9adaa0ef07a55aa428d3b2d1b1de70b83169811a663a8624b686166e5797f624dcc00178b9796e6
bf95976061 doc: add note about snapshot chainstate init (James O'Beirne)
e4d7995286 test: add testcases for snapshot initialization (James O'Beirne)
cced4e7336 test: move-only-ish: factor out LoadVerifyActivateChainstate() (James O'Beirne)
51fc9241c0 test: allow on-disk coins and block tree dbs in tests (James O'Beirne)
3c361391b8 test: add reset_chainstate parameter for snapshot unittests (James O'Beirne)
00b357c215 validation: add ResetChainstates() (James O'Beirne)
3a29dfbfb2 move-only: test: make snapshot chainstate setup reusable (James O'Beirne)
8153bd9247 blockmanager: avoid undefined behavior during FlushBlockFile (James O'Beirne)
ad67ff377c validation: remove snapshot datadirs upon validation failure (James O'Beirne)
34d1590331 add utilities for deleting on-disk leveldb data (James O'Beirne)
252abd1e8b init: add utxo snapshot detection (James O'Beirne)
f9f1735f13 validation: rename snapshot chainstate dir (James O'Beirne)
d14bebf100 db: add StoragePath to CDBWrapper/CCoinsViewDB (James O'Beirne)
Pull request description:
This is part of the [assumeutxo project](https://github.com/bitcoin/bitcoin/projects/11) (parent PR: https://github.com/bitcoin/bitcoin/pull/15606)
---
Half of the replacement for #24232. The original PR grew larger than expected throughout the review process.
This change adds the ability to initialize a snapshot-based chainstate during init if one is detected on disk. This is of course unused as of now (aside from in unittests) given that we haven't yet enabled actually loading snapshots.
Don't be scared! There are some big move-only commits in here.
Accompanying changes include:
- moving the snapshot coinsdb directory from being called `chainstate_[base blockhash]` to `chainstate_snapshot`, since we only support one snapshot in use at a time. This simplifies some logic, but it necessitates writing that base blockhash out to a file within the coinsdb dir. See [discussion here](https://github.com/bitcoin/bitcoin/pull/24232#discussion_r832762880).
- adding a simple fix in `FlushBlockFile()` that avoids a crash when attemping to flush to disk before `LoadBlockIndexDB()` is called, which happens when calling `MaybeRebalanceCaches()` during multiple chainstate init.
- improving the unittest to allow testing with on-disk chainstates - necessary to test a simulated restart and re-initialization.
ACKs for top commit:
naumenkogs:
utACK bf95976061
ariard:
Code Review ACK bf9597606
ryanofsky:
Code review ACK bf95976061. Changes since last review: rebasing, switching from CAutoFile to AutoFile, adding comments, switching from BOOST_CHECK to Assert in test util, using chainman.GetMutex() in tests, destroying one ChainstateManager before creating a new one in tests
fjahr:
utACK bf95976061
aureleoules:
ACK bf95976061
Tree-SHA512: 15ae75caf19f8d12a12d2647c52897904d27b265a7af6b4ae7b858592eeadb8f9da6c2394b6baebec90adc28742c053e3eb506119577dae7c1e722ebb3b7bcc0
c456302d42 doc: minor improvements in getutxos REST endpoint synopsis (Sebastian Falbesoner)
Pull request description:
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:
```
#### Blocks
`GET /rest/block/<BLOCK-HASH>.<bin|hex|json>`
`GET /rest/block/notxdetails/<BLOCK-HASH>.<bin|hex|json>`
```
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
ACKs for top commit:
stickies-v:
ACK c456302d42 - also checked that current master (cc12b8947) doesn't have any other lines changes that would require updates as per the outlined improvement points.
Tree-SHA512: b025aac0812397f5fbf78c805c13aeb5afa6862a049d13c0b101178799cdaff1ccd3abc368a5c103ea6ebf17cdff76584c54638d0f8d303d81ade2d71443d305
Check `port` options for invalid values (ports are parsed as uint16, so
in practice values >65535 are invalid; port 0 is undefined and therefore
considered invalid too). This allows for an early rejection of faulty
values and an supplying an informative message to the user.
Splits tests in `feature_proxy.py` to cover both invalid `hostname`
and `port` values.
Adds a release-note as previously valid `-port` and `-rpcport` values
can now result in errors.
a9d20eeceb doc: bump bips.md up-to-date version to v24.0 (Sebastian Falbesoner)
Pull request description:
This is a trivial follow-up to #26124.
ACKs for top commit:
jarolrod:
ACK a9d20eeceb
Tree-SHA512: 24c17c72498f96f9122d8fb041f1f6f63bd186e25ac3cb5a661bb1993106c6632f5efd95a15d19681004d30d38eca2d2a16b383a7a1f1c3db17f887ae1fcd02a
0811cbfc28 doc: add info about status code 404 for some rest endpoints (brunoerg)
Pull request description:
This PR adds an explanation about status code 404 for 2 endpoints (`/rest/tx/ `and `/rest/blockhashbyheight/`) in`REST-interface.md`. There are other endpoints that already cover it.
ACKs for top commit:
[deleted]:
reACK 0811cbfc28
shaavan:
ACK 0811cbfc28
Tree-SHA512: a01ac6653f706b7a7e4a4679a2b81e448381f31460ac4bcfc179af6186401cffae7b49a82f3a52c89e556acd5c16c159ce752c7a678177900ddf2e4e5c72fe6b
9580480570 Update debug logging section in the developer notes (Jon Atack)
1abaa31aa3 Update -debug and -debugexclude help docs for severity level logging (Jon Atack)
45f9282162 Create BCLog::Level::Trace log severity level (Jon Atack)
2a8712db4f Unit test coverage for -loglevel configuration option (klementtan)
eb7bee5f84 Create -loglevel configuration option (klementtan)
98a1f9c687 Unit test coverage for log severity levels (klementtan)
9c7507bf76 Create BCLog::Logger::LogLevelsString() helper function (klementtan)
8fe3457dbb Update LogAcceptCategory() and unit tests with log severity levels (klementtan)
c2797cfc60 Add BCLog::Logger::SetLogLevel()/SetCategoryLogLevel() for string inputs (klementtan)
f6c0cc0350 Add BCLog::Logger::m_category_log_levels data member and getter/setter (Jon Atack)
2978b387bf Add BCLog::Logger::m_log_level data member and getter/setter (Jon Atack)
f1379aeca9 Simplify BCLog::Level enum class and LogLevelToStr() function (Jon Atack)
Pull request description:
This is an updated version of https://github.com/bitcoin/bitcoin/pull/25287 and the next steps in parent PR #25203 implementing, with Klement Tan, user-configurable, per-category severity log levels based on an idea by John Newbery and refined in GitHub discussions by Wladimir Van der Laan and Marco Falke.
- simplify the `BCLog::Level` enum class and the `LogLevelToStr()` function and add documentation
- update the logging logic to filter logs by log level both globally and per-category
- add a hidden `-loglevel` help-debug config option to allow testing setting the global or per-category severity level on startup for logging categories enabled with the `-debug` configuration option or the logging RPC (Klement Tan)
- add a `trace` log severity level selectable by the user; the plan is for the current debug messages to become trace, LogPrint ones to become debug, and LogPrintf ones to become info, warning, or error
```
$ ./src/bitcoind -help-debug | grep -A10 loglevel
-loglevel=<level>|<category>:<level>
Set the global or per-category severity level for logging categories
enabled with the -debug configuration option or the logging RPC:
info, debug, trace (default=info); warning and error levels are
always logged. If <category>:<level> is supplied, the setting
will override the global one and may be specified multiple times
to set multiple category-specific levels. <category> can be:
addrman, bench, blockstorage, cmpctblock, coindb, estimatefee,
http, i2p, ipc, leveldb, libevent, lock, mempool, mempoolrej,
net, proxy, prune, qt, rand, reindex, rpc, selectcoins, tor,
util, validation, walletdb, zmq.
```
See the individual commit messages for details.
ACKs for top commit:
jonatack:
One final push per `git range-diff a5d5569 ce3c4c9 9580480` (should be trivial to re-ACK) to ensure this pull changes no default behavior in any way for users or the tests/CI in order to be completely v24 compatible, to update the unit test setup in general, and to update the debug logging section in the developer notes.
klementtan:
reACK 9580480570
1440000bytes:
reACK 9580480570
vasild:
ACK 9580480570
dunxen:
reACK 9580480
brunoerg:
reACK 9580480570
Tree-SHA512: 476a638e0581f40b5d058a9992691722e8b546471ec85e07cbc990798d1197fbffbd02e1b3d081b4978404e07a428378cdc8e159c0004b81f58be7fb01b7cba0
53e7ed075c doc: Release notes and other docs for migration (Andrew Chow)
9c44bfe244 Test migratewallet (Andrew Chow)
0b26e7cdf2 descriptors: addr() and raw() should return false for ToPrivateString (Andrew Chow)
31764c3f87 Add migratewallet RPC (Andrew Chow)
0bf7b38bff Implement MigrateLegacyToDescriptor (Andrew Chow)
e7b16f925a Implement MigrateToSQLite (Andrew Chow)
5b62f095e7 wallet: Refactor SetupDescSPKMs to take CExtKey (Andrew Chow)
22401f17e0 Implement LegacyScriptPubKeyMan::DeleteRecords (Andrew Chow)
35f428fae6 Implement LegacyScriptPubKeyMan::MigrateToDescriptor (Andrew Chow)
ea1ab390e4 scriptpubkeyman: Implement GetScriptPubKeys in Legacy (Andrew Chow)
e664af2976 Apply label to all scriptPubKeys of imported combo() (Andrew Chow)
Pull request description:
This PR adds a new `migratewallet` RPC which migrates a legacy wallet to a descriptor wallet. Migrated wallets will need a new backup. If a wallet has watchonly stuff in it, a new watchonly descriptor wallet will be created containing those watchonly things. The related transactions, labels, and descriptors for those watchonly things will be removed from the original wallet. Migrated wallets will not have any of the legacy things be available for fetching from `getnewaddress` or `getrawchangeaddress`. Wallets that have private keys enabled will have newly generated descriptors. Wallets with private keys disabled will not have any active `ScriptPubKeyMan`s.
For the basic HD wallet case of just generated keys, in addition to the standard descriptor wallet descriptors using the master key derived from the pre-existing hd seed, the migration will also create 3 descriptors for each HD chain in: a ranged combo external, a ranged combo internal, and a single key combo for the seed (the seed is a valid key that we can receive coins at!). The migrated wallet will then have newly generated descriptors as the active `ScriptPubKeyMan`s. This is equivalent to creating a new descriptor wallet and importing the 3 descriptors for each HD chain. For wallets containing non-HD keys, each key will have its own combo descriptor.
There are also tests.
ACKs for top commit:
Sjors:
tACK 53e7ed075c
w0xlt:
reACK 53e7ed075c
Tree-SHA512: c0c003694ca2e17064922d08e8464278d314e970efb7df874b4fe04ec5d124c7206409ca701c65c099d17779ab2136ae63f1da2a9dba39b45f6d62cf93b5c60a
59aa54f731 i2p: log "SAM session" instead of "session" (Vasil Dimov)
d7ec30b648 doc: add release notes about the I2P transient addresses (Vasil Dimov)
47c0d02f12 doc: document I2P transient addresses usage in doc/i2p.md (Vasil Dimov)
3914e472f5 test: add a test that -i2pacceptincoming=0 creates a transient session (Vasil Dimov)
ae1e97ce86 net: use transient I2P session for outbound if -i2pacceptincoming=0 (Vasil Dimov)
a1580a04f5 net: store an optional I2P session in CNode (Vasil Dimov)
2b781ad66e i2p: add support for creating transient sessions (Vasil Dimov)
Pull request description:
Add support for generating a transient, one-time I2P address for ourselves when making I2P outbound connection and discard it once the connection is closed.
Background
---
In I2P connections, the host that receives the connection knows the I2P address of the connection initiator. This is unlike the Tor network where the recipient does not know who is connecting to them, not even the initiator's Tor address.
Persistent vs transient I2P addresses
---
Even if an I2P node is not accepting incoming connections, they are known to other nodes by their outgoing I2P address. This creates an opportunity to white-list given nodes or treat them differently based on their I2P address. However, this also creates an opportunity to fingerprint or analyze a given node because it always uses the same I2P address when it connects to other nodes. If this is undesirable, then a node operator can use the newly introduced `-i2ptransientout` to generate a transient (disposable), one-time I2P address for each new outgoing connection. That address is never going to be reused again, not even if reconnecting to the same peer later.
ACKs for top commit:
mzumsande:
ACK 59aa54f731 (verified via range-diff that just a typo / `unique_ptr` initialisation were fixed)
achow101:
re-ACK 59aa54f731
jonatack:
utACK 59aa54f731 reviewed range diff, rebased to master, debug build + relevant tests + review at each commit
Tree-SHA512: 2be9b9dd7502b2d44a75e095aaece61700766bff9af0a2846c29ca4e152b0a92bdfa30f61e8e32b6edb1225f74f1a78d19b7bf069f00b8f8173e69705414a93e
1dc03dda05 [doc] remove non-signaling mentions of BIP125 (glozow)
32024d40f0 scripted-diff: remove mention of BIP125 from non-signaling var names (glozow)
Pull request description:
We have pretty thorough documentation of our RBF policy in doc/policy/mempool-replacements.md. It enumerates each rule with several sentences of rationale. Also, each rule pretty much has its own function (3 and 4 share one), with extensive comments. The doc states explicitly that our rules are similar but differ from BIP125, and contains a record of historical changes to RBF policy.
We should not use "BIP125" as synonymous with our RBF policy because:
- Our RBF policy is different from what is specified in BIP125, for example:
- the BIP does not mention our rule about the replacement feerate being higher (our Rule 6)
- the BIP uses minimum relay feerate for Rule 4, while we have used incremental relay feerate since #9380
- the "inherited signaling" question (CVE-2021-31876). Call it discrepancy, ambiguous wording, doc misinterpretation, or implementation details, I would recommend users refer to doc/policy/mempool-replacements.md
- the signaling policy is configurable, see #25353
- Our RBF policy may change further
- We have already marked BIP125 as only "partially implemented" in docs/bips.md since 1fd49eb498
- See comments from people who are not me recently:
- https://github.com/bitcoin/bitcoin/pull/25038#discussion_r909507429
- https://github.com/bitcoin/bitcoin/pull/25575#issuecomment-1179519204
This PR removes all non-signaling mentions of BIP125 (if people feel strongly, we can remove all mentions of BIP125 period). It may be useful to refer to the concept of "tx opts in to RBF if it has at least one nSequence less than (0xffffffff - 1)" as "BIP125 signaling" because:
- It is succint.
- It has already been widely marketed as BIP125 opt-in signaling.
- Our API uses it when referring to signaling (e.g. getmempoolentry["bip125-replaceable"] and wallet error message "not BIP 125 replaceable"). Changing those is more invasive.
- If/when we have other ways to signal in the future, we can disambiguate them this way. See #25038 which proposes another way of signaling, and where I pulled these commits from.
Alternatives:
- Changing our policy to match BIP125. This doesn't make sense as, for example, we would have to remove the requirement that a replacement tx has a higher feerate (Rule 6).
- Changing BIP125 to match what we have. This doesn't make sense as it would be a significant change to a BIP years after it was finalized and already used as a spec to implement RBF in other places.
- Document our policy as a new BIP and give it a number. This might make sense if we don't expect things to change a lot, and can be done as a next step.
ACKs for top commit:
darosior:
ACK 1dc03dda05
ariard:
ACK 1dc03dda
t-bast:
ACK 1dc03dda05
Tree-SHA512: a3adc2039ec5785892d230ec442e50f47f7062717392728152bbbe27ce1c564141f85253143f53cb44e1331cf47476d74f5d2f4b3cd873fc3433d7a0aa783e02
a6b0c1fcc0 doc: add releases notes for 25504 (listsinceblock updates) (Antoine Poinsot)
0fd2d14454 rpc: add an include_change parameter to listsinceblock (Antoine Poinsot)
55f98d087e rpc: output parent wallet descriptors for coins in listunspent (Antoine Poinsot)
b724476158 rpc: output wallet descriptors for received entries in listsinceblock (Antoine Poinsot)
55a82eaf91 wallet: allow to fetch the wallet descriptors for a given Script (Antoine Poinsot)
Pull request description:
Wallet descriptors are useful for applications using the Bitcoin Core wallet as a backend for tracking coins, as they allow to track coins for multiple descriptors in a single wallet. However there is no information currently given for such applications to link a coin with an imported descriptor, severely limiting the possibilities for such applications of using multiple descriptors in a single wallet. This PR outputs the matching imported descriptor(s) for a given received coin in `listsinceblock` (and friends).
It comes from a need for an application i'm working on, but i think it's something any software using `bitcoind` to track multiple descriptors in a single wallet would have eventually. For instance i'm thinking about the BDK project. Currently, the way to achieve this is to import raw addresses with labels and to have your application be responsible for wallet things like the gap limit.
I'll add this to the output of `listunspent` too if this gets a few Concept ACKs.
ACKs for top commit:
instagibbs:
ACK a6b0c1fcc0
achow101:
re-ACK a6b0c1fcc0
Tree-SHA512: 7a5850e8de98b439ddede2cb72de0208944f8cda67272e8b8037678738d55b7a5272375be808b0f7d15def4904430e089dafdcc037436858ff3292c5f8b75e37
544b4332f0 Add wallet tests for spending rawtr() (Pieter Wuille)
e1e3081200 If P2TR tweaked key is available, sign with it (Pieter Wuille)
8d9670ccb7 Add rawtr() descriptor for P2TR with unknown tweak (Pieter Wuille)
Pull request description:
It may be useful to be able to represent P2TR outputs in descriptors whose script tree and/or internal key aren't known. This PR does that, by adding a `rawtr(KEY)` descriptor, where the KEY represents the output key directly. If the private key corresponding to that output key is known, it also permits signing with it.
I'm not convinced this is desirable, but presumably "tr(KEY)" sounds more intended for direct use than "rawtr(KEY)".
ACKs for top commit:
achow101:
ACK 544b4332f0
sanket1729:
code review ACK 544b4332f0
w0xlt:
reACK 544b4332f0
Tree-SHA512: 0de08de517468bc22ab0c00db471ce33144f5dc211ebc2974c6ea95709f44e830532ec5cdb0128c572513d352120bd651c4559516d4500b5b0a3d257c4b45aca
Our RBF policy is different from the rules specified in BIP125. For
example, the BIP does not mention Rule 6, and our Rule 4 uses the
(configurable) incremental relay feerate (distinct from the
minimum relay feerate). Those interested in our policy should refer to
doc/policy/mempool-replacements.md instead. These rules may also
continue to diverge with package RBF and other RBF improvements. Keep
references to the BIP125 signaling wrt sequence numbers, since that is
still correct and widely used. It is helpful to refer to this as "BIP125
signaling" since it is unambiguous and succint, especially if we have
multiple ways to signal replaceability in the future.
The rule numbers in doc/policy/mempool-replacements.md correspond
largely to those of BIP 125, so we can still refer to them like "Rule 5."
ab3c06db1a doc: Release notes for default RBF (Andrew Chow)
61d9149e78 rpc: Default rbf enabled (Andrew Chow)
e3c33637ba wallet: Enable -walletrbf by default (Andrew Chow)
Pull request description:
The GUI currently opts in to RBF by default, but RPCs do not, and `-walletrbf` is default disabled. This PR makes the default in those two places to also opt in.
The last time this was proposed (#9527), the primary objections were the novelty at the time, the inability to bump transactions, and the gui not having the option to disable rbf. In the 5 years since, RBF usage has steadily grown, with ~27% of txs opting in. The GUI has the option to enable/disable RBF, and is also defaulted to having it enabled. And we have the ability to bump RBF'd transactions in both the RPC and the GUI. So I think it makes sense to finally change the default to always opt in to RBF.
ACKs for top commit:
darosior:
reACK ab3c06db1a
aureleoules:
ACK ab3c06db1a.
glozow:
utACK ab3c06db1a
Tree-SHA512: 81b012c5033e270f86a87a6a196ccc549eb54b158eebf88e917cc6621d40d7bdcd1566b602688907dd5d364b95a557b29f97dce869cea512e339588262c027b6
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
