256482ab56 validation: In AcceptBlock, ignore flush result (optout)
Pull request description:
Shortcut: see https://github.com/bitcoin/bitcoin/pull/35570#issuecomment-4827437071 and https://github.com/bitcoin/bitcoin/pull/29700#discussion_r3488550312 .
**Summary.** At the end of `ChainstateManager::AcceptBlock`, the flushing of the chain state is initiated, but any potential failure from `FlushStateToDisk` is ignored. However, the error message might get propagated upwards. This change makes sure that both the error status and the error message are ignored, and adds an explanatory comment.
**Related/background.** The potential inconsistency between the return value and state returned from `AcceptBlock` was found during refactoring of the return of `BlockValidationState` in #35570. PR #29700 also touches this part by adding an explanatory comment, see https://github.com/bitcoin/bitcoin/pull/29700#discussion_r3488550312 . Splitting this minor behavior change out of #35570 makes that PR a clean (no-bahavior-change) refactor (this option was mentioned from the start, and also proposed by reviewers; see: https://github.com/bitcoin/bitcoin/pull/35570#issuecomment-4827437071 ).
**Motivation**
- Get rid of the potential inconsistency between the return value (`true`) and state returned (`Error`). This facilitates refactoring of the error returns in #35570.
- Make the ignoring clear and explicit, so there is no doubt about it being intentional or not.
**Details.** `ChainstateManager::AcceptBlock` is called for new block candidates. After checks and inclusion, it triggers flushing of the updated chain state to disk, by calling `Chainstate::FlushStateToDisk`. This method returns a bool and also takes & returns a `BlockValidationState` state. In case of error it returns `false`, and sets the state (to `Error`) and the reject reason string. At the call site, the return value is ignored, but for the state the state variable of `AcceptBlock` is provided, so an Error state may get propagated upwards in the call chain. A caller may react to this Error state.
**Rationale for ignoring the flush error**
The validation code flushes internally in several places, and mostly doesn't treat flush failures as errors returned to callers. Disk errors should never be mistreated as block validation failure. Note that the fatal error notification inside `FlushStateToDisk` still fires, so the node will shut down on unrecoverable flush errors regardless.
**Relevant use case.** `AcceptBlock` is called from the following methods (excluding test code):
- `ChainstateManager::ProcessNewBlock`
- Twice from `ChainstateManager::LoadExternalBlockFile`
Of these, in two places the `state` returned is not used at all. Only at `validation.cpp:5056` is the state used.
```
BlockValidationState state;
if (AcceptBlock(pblock, state, nullptr, true, dbp, nullptr, true)) {
nLoaded++;
}
if (state.IsError()) {
break;
}
```
Here a flush error *may* trigger the `break`, causing an early exit from the loop over blocks in a block file. Post-change the returned state will not be `Error` in a disk error case, so the `break` will not be hit here. However:
- This branch is only called for blocks that are not known yet
- In case of disk error case the fatal error handler will cause the node to shut down in any case.
Based on the above, the change in error return behavior is acceptable.
ACKs for top commit:
maflcko:
lgtm ACK 256482ab56
l0rinc:
lightly tested ACK 256482ab56
dergoegge:
Code review ACK 256482ab56
sedited:
ACK 256482ab56
ismaelsadeeq:
ACK 256482ab56
Tree-SHA512: c72747b5725739117d6061c3b3d5e6910bd06325a072b20708475c8e178a7ad8a6509b30cc8b547c92011a1267e4ad2feef31a992110072e5f37a4ac1f5c79d8
Pure `getifaddrs()`/`freeifaddrs()` calls do not need any type
definitions beyond those provided by `<ifaddrs.h>` itself.
The subsequent `struct ifaddrs` processing in `netif.cpp` does not
involve any symbols from `<sys/types.h>`.
9a8ef9b0a3 test: SOCKS5 proxy: expect that connection may be reset during handshake (Vasil Dimov)
eb3208364a test: SOCKS5 proxy: expect that connection may be reset when forwarding (Vasil Dimov)
Pull request description:
The `forward_sockets()` function used by the SOCKS5 proxy forwards data between two connected sockets. It might happen that one of those sockets gets closed/reset abruptly, without sending EOF first. This is to be expected if e.g. `bitcoind` is shutdown and shouldn't result in noisy harmless messages like:
```
2026-06-03T13:23:56.966859Z TestFramework.socks5 (ERROR): socks5 request handling failed (running True)
Traceback (most recent call last):
File ".../socks5.py", line 199, in handle
forward_sockets(self.conn, conn_to, self.wakeup_socket_pair[1], self.serv)
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File ".../socks5.py", line 76, in forward_sockets
data = s.recv(4096)
ConnectionResetError: [Errno 104] Connection reset by peer
```
Instead turn this into a debug log message with a nice prefix containing enough information to identify the two forwarded sockets.
---
Also expect that the connection might be closed during the SOCKS5 handshake and only log a debug message if that happens.
ACKs for top commit:
optout21:
crACK 9a8ef9b0a3
danielabrozzoni:
reACK 9a8ef9b0a3
sedited:
ACK 9a8ef9b0a3
Tree-SHA512: 24e25a30529eda3536ebf472f63a93fd80fff46273054a7075490c88737f8870c0141b2bc99d9ef39e6b4f592af2801350fdfbc71927f573738b4a14f5fd7ce0
b2de59d486 wallet, bdbro: Validate btree page levels (Ava Chow)
dc3a2b9c3b wallet, bdbro: Enforce overflow data lengths (Ava Chow)
Pull request description:
Alternative to #34946
BDB's overflow records include the total length of the data to be read from the overflow pages. If this length is impossible (larger than max page * page size), or if the data that we are reading exceeds the stated length, then throw an exception as this is an invalid BDB file. This prevents infinite looping if an overflow page makes a circular reference.
BDB BTrees also include the level in the tree that the page is supposed to be at. Leaf pages are always at level 1. Starting from the root page, we can validate that each child has a level one less than the parent, until we reach a leaf page with a level of 1. This also ensures that we cannot have circular internal page references.
ACKs for top commit:
sedited:
ACK b2de59d486
rkrux:
code review ACK b2de59d486
Tree-SHA512: b740c349f68c78150ee57b77e8e81605bb45a7db4fbca3c3a0d87318178dfa197f37faf0cbfd8bef791ab20f4a9afc3d2571842960055a70b6c081d605f59f94
095596ddf7 log: expose -logratelimit option (Lőrinc)
Pull request description:
Follow-up to https://github.com/bitcoin/bitcoin/pull/32604#issuecomment-4804334291
**Problem:** `-logratelimit` is currently registered as `DEBUG_ONLY`, so users who are not reading `-help-debug` are unlikely to discover the supported escape hatch when rate limiting interferes with diagnosis or log processing.
**Fix:** Expose the existing option in normal help while keeping rate limiting enabled by default.
Add argsman coverage to assert that `-logratelimit` is not `DEBUG_ONLY` and appears in the default help text.
**Reproducer:** you can check manually by grepping the help page or by adding a temporary unit test - before and after the change and see the difference.
<details><summary>bitcoind -help(-debug)</summary>
```bash
cmake -B build && cmake --build build -j -t bitcoind
build/bin/bitcoind -help-debug | grep -A2 logratelimit
build/bin/bitcoind -help | grep -A2 logratelimit
```
</details>
<details><summary>util_LogRateLimitHelp</summary>
```patch
diff --git a/src/test/argsman_tests.cpp b/src/test/argsman_tests.cpp
index da0d684050..0e918afd6b 100644
--- a/src/test/argsman_tests.cpp
+++ b/src/test/argsman_tests.cpp
@@ -3,6 +3,7 @@
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
#include <common/args.h>
+#include <init/common.h>
#include <sync.h>
#include <test/util/logging.h>
#include <test/util/setup_common.h>
@@ -710,6 +711,14 @@ BOOST_AUTO_TEST_CASE(util_AddCommand_clearargs_replaces_command_options)
BOOST_CHECK(details.empty());
}
+BOOST_AUTO_TEST_CASE(util_LogRateLimitHelp)
+{
+ ArgsManager args;
+ init::AddLoggingArgs(args);
+ BOOST_CHECK_EQUAL(*Assert(args.GetArgFlags("-logratelimit")) & ArgsManager::DEBUG_ONLY, 0U);
+ BOOST_CHECK(args.GetHelpMessage().find("-logratelimit") != std::string::npos);
+}
+
BOOST_AUTO_TEST_CASE(util_GetChainTypeString)
{
TestArgsManager test_args;
```
</details>
ACKs for top commit:
Crypt-iQ:
crACK 095596ddf7
stickies-v:
ACK 095596ddf7
janb84:
ACK 095596ddf7
sedited:
ACK 095596ddf7
Tree-SHA512: ff5bad5ee72616a3fbe0438c675d9c3c0f60a0999433e7e0cee259f3b7ad1edd05e5baeeb6e02c649bc9780006bbc907333b4ce962c11588a1d633e0bae19272
9f3e427228 fuzz: Remove ConsumeUniValue (marcofleon)
Pull request description:
Addresses https://github.com/bitcoin/bitcoin/pull/35118#discussion_r3514230802.
`ConsumeUniValue` isn't that useful as a shared fuzz helper, as it just returns the same hard-coded fields. This PR removes it and updates the `ipc` target to read a UniValue directly from fuzzer input instead. This is similar to what the `parse_univalue` target already does, and lets `ipc` test with different JSON values instead of one fixed value.
ACKs for top commit:
sedited:
ACK 9f3e427228
brunoerg:
code review ACK 9f3e427228
Tree-SHA512: 5bc0957c426b185392aabf5c74411758e93bc8e75e9896b08774b33d5ec8ba9c223499a139b03a94dcf907b73552962df9a9b059e875f40048707a87a69bf7c5
The helper created a UniValue with hard-coded constants, which
isn't ideal for fuzz tests. Replace it in the ipc fuzz test with
parsing a UniValue directly from the fuzzed data provider.
9b2ef81757 doc: add release notes for #33671 (getbalances nonmempool field) (Pablo Martin)
Pull request description:
This is a follow-up to #33671.
Top commit has no ACKs.
Tree-SHA512: 0572b121ff74b3a455355f03d3297f5c779313d7d7e1ad258d46f2d44980d6140280cbd8c367828e6db7b8243d7cc485bde7367edae4415afef0db7b70c23713
47bbed052e ci: use true|false over "true|false" (fanquake)
9a25bc3989 ci: use a 8x instance over 16x (fanquake)
Pull request description:
Follows up to https://github.com/bitcoin/bitcoin/pull/31425#discussion_r3453058552.
ACKs for top commit:
sedited:
ACK 47bbed052e
Tree-SHA512: 518794115550d744e2bae048858299ebb83f2d3678aa7ba088928fc54a497aa1bc9a55ccaf31cdd615eaac13e22c037ac1df663ce581acec9392eff4414f4987
f595daf1dd test: ensure HTTPServer race condition is fixed (Matthew Zipkin)
b98b10c072 test: introduce a worker thread in http socket error test (Matthew Zipkin)
922b08d375 test: socket error handling in HTTPServer using ErrorSock mock socket (Matthew Zipkin)
73da2a8a52 http: prevent race condition between worker thread and I/O thread (Matthew Zipkin)
Pull request description:
This prevents a losing race condition that could prevent the server from reading any more requests from an HTTP client.
Found and reported by the fuzzing department: 7fe5f54497
The Race:
A connected socket can either be written to or read from based on the result of `GenerateWaitSockets()`. That method checks the `HTTPRemoteClient` flag `m_send_ready`. If it's `true` the implication is that there is data in the client's send buffer ready to go. Once that data is sent and the buffer is empty, `MaybeSendBytesFromBuffer()` sets it `false` again.
The sad case was when a worker thread calling `WriteReply()` adds data to the send buffer, but before it sets `m_send_ready` to `true`, the I/O thread sends that data and empties the buffer. With the buffer unexpectedly empty, `WriteReply()` sets `m_send_ready` to `true`.
The effect of this is that the socket will stay in "write" mode with nothing to write. With nothing to write, `MaybeSendBytesFromBuffer()` never sets it back to `false` and the socket is stuck forever.
The Fix:
Simply move `m_send_ready = true` inside the block of `WriteReply()` where `m_send_mutex` is still held. This prevents the I/O thread from emptying the send buffer while the worker thread is setting the flag.
Testing:
To observe the race condition, revert the first commit `"http: prevent race condition between worker thread and I/O thread"` and run the unit test from the remainder of the branch. I like to see the logs:
`test_bitcoin --log_level=all --run_test=httpserver_tests -- --printtoconsole --debug=http --debug=lock'
The test will fail with a small probability. The socket will get stuck and the test will abort after a 60 second timeout. To garuntee the race condition loses and fail the test every time, slow down `WriteReply()` in the worker thread:
```diff
diff --git a/src/httpserver.cpp b/src/httpserver.cpp
index 99e30ff663..b0c7b516d8 100644
--- a/src/httpserver.cpp
+++ b/src/httpserver.cpp
@@ -614,6 +614,7 @@ void HTTPRequest::WriteReply(HTTPStatusCode status, std::span<const std::byte> r
} else {
// Inform HTTPServer I/O that data is ready to be sent to this client
// in the next loop iteration.
+ std::this_thread::sleep_for(500ms);
m_client->m_send_ready = true;
}
```
With the first commit (the fix) back in place, slowing down the worker thread like this won't fail the test.
Bonus:
The unit test is spread over three commits. First, a method of the socket testing setup is templated so a mock socket that intentionally raises an error can be inserted. The unit test added in that commit covers a race condition that was fixed in #35182 in response to https://github.com/bitcoin/bitcoin/pull/35182/changes#r3358889539 so we get the added benefit of covering an error path, and guaranteeing coverage of both "optimistic send" (directly from worker thread) and regular send (from a tick in the I/O loop thread).
The next commit adds a worker thread to the unit test, at which point a race condition is possible but very unlikely because all requests are sent at once. Finally, we spread out the requests in the top commit and make the race condition much easier to catch.
ACKs for top commit:
janb84:
crACK f595daf1dd
dergoegge:
utACK f595daf1dd
theStack:
Code-review ACK f595daf1dd
Tree-SHA512: 451982fd72724c4115e371fc6392605693d6c3207f00ffebcf027aae9253f7974b5b1165b9f46c91b5436d7fe60c7d27316fb0b79f729ab0bf8f32db2530075f
a15bdc0598 doc: update offline-signing-tutorial to use exportwatchonlywallet rpc (Pol Espinasa)
a388076401 test: Test for exportwatchonlywallet (Ava Chow)
d053e3e5c8 wallet, rpc: Add exportwatchonlywallet RPC (Ava Chow)
444878efef wallet: Add CWallet::ExportWatchOnly (Ava Chow)
f9273f01db wallet: Move listdescriptors retrieving from RPC to CWallet (Ava Chow)
a1c83789a7 wallet: Write new descriptor's cache in AddWalletDescriptor (Ava Chow)
1e996640e6 wallet: Use Descriptor::CanSelfExpand() in CanGetAddresses() (Ava Chow)
d2ee9227da descriptor: Add CanSelfExpand() (Ava Chow)
Pull request description:
Currently, if a user wants to use an airgapped setup, they need to manually create the watchonly wallet that will live on the online node by importing the public descriptors. This PR introduces `exportwatchonlywallet` which will create a wallet file with the public descriptors to avoid exposing the specific internals to the user. Additionally, this RPC will copy any existing labels, transactions, and wallet flags. This ensures that the exported watchonly wallet is almost entirely a copy of the original wallet but without private keys.
ACKs for top commit:
polespinasa:
lgtm ACK a15bdc0598
Sjors:
re-utACK a15bdc0598
pablomartin4btc:
re-ACK [a15bdc0](a15bdc0598)
w0xlt:
lgtm reACK a15bdc0598
Tree-SHA512: cfc59415ad9aa13d1445cf2a85db1c051215496b6edcf5a8db463499b2b51b92ee7bf840b709035dff7635f9d0c533423bceb58c851f220500e1ea254d12f3b8
fb1d152c24 depends: Boost 1.91.0-1 (fanquake)
Pull request description:
https://www.boost.org/releases/1.91.0/.
> MultiIndex
> Breaking change: All type lists accepted or provided by the library (indexed_by, tag, nested typedefs index_specifier_type_list, index_type_list, iterator_type_list and const_iterator_type_list) are no longer based on [Boost.MPL](https://www.boost.org/libs/mpl) but instead they are now [Boost.Mp11 lists](https://www.boost.org/libs/mp11/doc/html/mp11.html#definitions). As a result, Boost.MultiIndex doesn’t depend anymore on Boost.MPL. It is expected that most user code won’t be impacted by this change, but the previous behavior may be restored, however, by globally defining the macro BOOST_MULTI_INDEX_ENABLE_MPL_SUPPORT. Legacy support for Boost.MPL may be eventually deprecated and removed in the future.
> Breaking change: composite_key and associated class templates (composite_key_equal_to, composite_key_compare, composite_key_hash) have been made variadic (previously the maximum number of template arguments was limited by BOOST_MULTI_INDEX_LIMIT_COMPOSITE_KEY_SIZE). This change should be transparent to users, with the exception that composite_key::key_extractors returns a std::tuple instead of a boost::tuple (and similarly for the rest of affected class templates).
> Removed internal workarounds and fallbacks to support pre-C++11 compilers.
ACKs for top commit:
hebasto:
re-ACK fb1d152c24.
willcl-ark:
ACK fb1d152c24
Tree-SHA512: 08a12d5f2b184faea8a0c68a276e6a11ebeb0dbedfa9e0976d80d49d5cbcee20fec07d77ee90399e0d35a18068755973e30d8451e22e7a151efaded30c7bfcb1
ExportWatchOnly produces a watchonly wallet file from a CWallet. This
can be restored onto another instance of Bitcoin Core to allow that
instance to watch the same descriptors, and also have all of the same
initial address book and transactions.
When listdescriptors retrieves the descriptors from the wallet, instead
of having this logic in the RPC, move it into CWallet itself. This
will enable other functions to get the descriptors in an exportable
form.
037ad77071 fuzz: add IPC round-trip target (Enoch Azariah)
8a739a5510 build: allow ipc fuzz builds (Enoch Azariah)
Pull request description:
As discussed in #23015, this PR adds an IPC fuzz target to exercise the Cap'n Proto/libmultiprocess serialization bridge using an in-process two-way pipe and a reflected test interface.
It covers round-trip serialization for `COutPoint`, `CScript`, `std::vector<uint8_t>`, `UniValue`, and transactions, and exercises libmultiprocess proxy/server interaction. The target guarantees at least one IPC operation per input and is included by default when IPC is enabled in fuzz builds
Coverage [report](https://marcofleon.github.io/coverage/ipc/) provided by marcofleon
ACKs for top commit:
marcofleon:
ACK 037ad77071
sedited:
Re-ACK 037ad77071
Tree-SHA512: aae8835c8a378886b36420c422136c743b235877f6fd6f0c681910903c68e18753598c7f0e0279ce2e64d627241ce3a4e08f7edecc2e38765569c9faa61bf45e
91586f701e test: introduce NodeSigner, run feature_taproot.py without wallet compiled (Sebastian Falbesoner)
771200ca43 test: return full keypair from `getnewdestination` helper (Sebastian Falbesoner)
Pull request description:
This PR introduces a simple `NodeSigner` wallet replacement class that delegates signing to a specified node via the `signrawtransactionwithkey` RPC. Note that this is fundamentally different to `MiniWallet`, as it allows spending standard output types (P2PKH, P2WPKH, P2SH-P2WPKH, P2TR) and operates on already existing raw transactions, rather than allowing to create them from scratch (though support for that could still be added later).
A `NodeSigner` instance is plugged into the taproot functional test (`feature_taproot.py`) in order to allow running without having the Bitcoin Core wallet compiled. This was done with the intention to change the nature of this functional test as little as possible, as it seems that the variety of additional (pre-taproot) output script types and a rather sophisticated scheme for deriving amounts (including change) is desired -- if this is not considered relevant, a more invasive replacement using MiniWallet might also be a possible alternative.
ACKs for top commit:
maflcko:
review ACK 91586f701e 🏗
brunoerg:
code review ACK 91586f701e
Tree-SHA512: 20c047268261ce5c9517bae5e3d71e9313de149841273451df8639bd81009b933b7061c4881651a345c12e11b311ff746feb2dee84ee9b19dd57e18bb7fe3fee
b36730a3ef Add CI job for riscv bare metal (TheCharlatan)
bfdbf513f6 Add CI job for producing a static bare metal binary (TheCharlatan)
a9a1d92a1d build: Add option for building for bare metal envs (TheCharlatan)
Pull request description:
This adds a CI job for building the static consensus library and linking it to an executable. It uses newlib-cygwin as a C library for the final linking step. This ensure compatibility with this target going forward and can serve as a starting point for enabling bare metal builds for the entire kernel library. This would have also caught the error fixed in #31365.
ACKs for top commit:
fanquake:
ACK b36730a3ef
willcl-ark:
reACK b36730a3ef
Tree-SHA512: c199260f243e20df7f6a537e6c1eaf3d32e23f8fc78b9a8e2b75d9feff3830ef61279e93093dacdceb99e8eb010321b4c1c644e2ad9e266f0ca1ae736baa20ae
Document that newly indexed `txospenderindex` entries use less disk space and that existing indexes remain readable.
Users only need to rebuild the index if they want previously indexed entries rewritten with the smaller marker.
`TxoSpenderIndex` uses LevelDB values only as presence markers. `FindSpender` iterates over keys and loads the spending transaction from the disk position stored in each key.
Write new entries with a zero-byte span instead of a serialized empty string, so rebuilt indexes avoid one extra byte per spender entry.
Existing indexes remain readable because the lookup path does not deserialize the marker value.
Add an ipc fuzz target behind ENABLE_IPC.
Set up an in-process two-way pipe and use a small reflected interface
to exercise libmultiprocess client/server calls.
Round-trip COutPoint, CScript, std::vector<uint8_t>, UniValue, and
transactions.
Add bitcoin_ipc_fuzz static library and link it to the fuzz target
via a new src/ipc/test/fuzz/CMakeLists.txt.
b6b1d0653a nanobench: fix perf counter buffer init (Lőrinc)
Pull request description:
**Problem:** The Linux perf counter buffers are documented as starting with three `read_format` metadata slots, but `std::vector<uint64_t>{3}` creates a one-element vector containing `3`.
In normal benchmark runs this is usually hidden because successful `monitor()` calls resize the buffers before `updateResults()`, while failed setup sets `mHasError` before the indexed reads.
**Fix:** Use the vector size constructor so the buffers start with three zero-initialized metadata slots.
This should not change the usual successful benchmark path, but it makes the default object state match the code's indexing assumptions.
**Reproducer:** https://godbolt.org/z/scE8rMd8Y
**Upstream:** https://github.com/martinus/nanobench/pull/138
ACKs for top commit:
dergoegge:
Code review ACK b6b1d0653a
sedited:
ACK b6b1d0653a
Tree-SHA512: f3055e3eaf567e46e99c02497563249a292162606945365a277beacfd95086b5645f67396bfa4f1e08ca109ddd48a6feef3ead6d59b8de8ae898607493ee13ca
d64ea15824 ci: add openBSD cross CI job (fanquake)
5404b62074 depends: add openbsd_LDFLAGS (fanquake)
Pull request description:
This adds a Linux cross job for OpenBSD; similar to https://github.com/bitcoin/bitcoin/pull/34491 (FreeBSD).
ACKs for top commit:
hebasto:
ACK d64ea15824.
willcl-ark:
ACK d64ea15824
Tree-SHA512: 0353c0ae8dd49c861a9100ebd5044fc39227c29859ca68e6454ebdf469c90ff5471e29733613606ee8ba72037f7fca5086275f794e90864a6456ffee73d9113b
Introduce a new simple `NodeSigner` wallet replacement that delegates
signing to a specified node via the `signrawtransactionwithkey` RPC,
and plug in that new class to the functional test feature_taproot.py,
so that it can be ran without the Bitcoin Core wallet compiled.
This can be useful for spending funds that are received at the created
address. Preparatory for the next commit, which modifies the taproot
functional test to work without the Bitcoin Core wallet compiled in.
3765b428d1 logging: More fully remove libevent log category (Ryan Ofsky)
Pull request description:
Libevent log category was partially removed in 39e9099da5, and this commit extends that with the following changes:
- Stops showing libevent in the list of supported log categories in `bitcoind -help` and `bitcoin-cli help logging` output.
- Stops returning `"libevent": false` in `logging` RPC output.
It's not good to treat libevent as a supported log category when it can't be enabled and trying to enable it results in warnings.
There's also no need to define an unused LIBEVENT constant value and keep more complicated logic for dealing with deprecated log categories, so this change also simplifies code internally.
ACKs for top commit:
l0rinc:
code review ACK 3765b428d1
pinheadmz:
ACK 3765b428d1
sedited:
ACK 3765b428d1
Tree-SHA512: 09e9514f905bb0a79d870689af491886baaa31fa19f2ad6aef4283fa20c2fa6ce8d384178139227aeeabffabff6e83d254114daaeefbbfe2c6172b9da8871298
a318f43254 bitcoin-util: Add netmagic command (ekzyis)
Pull request description:
This adds a `netmagic` command to `bitcoin-util`. It will return the network magic bytes of the selected chain:
```
$ bitcoin-util netmagic
f9beb4d9
$ bitcoin-util -regtest netmagic
fabfb5da
$ bitcoin-util -testnet4 netmagic
1c163f28
$ bitcoin-util -signet netmagic
0a03cf40
# default challenge
$ bitcoin-util -signet -signetchallenge=512103ad5e0edad18cb1f0fc0d28a3d4f1f3e445640337489abb10404f2d1e086be430210359ef5021964fe22d6f8e05b2463c9540ce96883fe3b278760f048f5189f2e6c452ae netmagic
0a03cf40
$ bitcoin-util -signet -signetchallenge=51 netmagic
54d26fbd
```
This will be particularly useful for https://github.com/bitcoin/bitcoin/pull/34566 to determine the datadir path of a custom signet, before starting bitcoind, since #34566 will add the network magic as a suffix. This was mentioned in https://github.com/bitcoin/bitcoin/pull/34566#issuecomment-4622356132. It uses the same code from init.cpp to print the signet derived magic:
ea9afb61a1/src/init.cpp (L967-L969)
Since it does not depend on #34566, and the changes are quite simple, I created a separate PR for this for easier review and discussion.
I have tested this by invoking the command with the options above.
ACKs for top commit:
stickies-v:
ACK a318f43254
sedited:
ACK a318f43254
Tree-SHA512: bcb5a1b14260e13a35f5682e4dac735f472ab6ff7781e7e77aef5895ddbecc03a2fc72a26419ba9a28354736a1eaaeddb047bafe276440e339f17ddfe7841862
2ee4fafa3f test: add fuzz test for private broadcast (kevkevinpal)
08b7c61fc7 private broadcast: enforce sending to unique node ids (Vasil Dimov)
Pull request description:
Add a fuzz test that exercises the public methods of the `PrivateBroadcast` class from `src/private_broadcast.h` and checks for correctness.
ACKs for top commit:
instagibbs:
ACK 2ee4fafa3f
nervana21:
re-ACK 2ee4fafa3f
frankomosh:
Code Review ACK 2ee4fafa3f.
Tree-SHA512: 35f9efcf9e7ea8bd071f6b607fd7c901b60ccf14610f501e6cf06f0d05c389424ab8a0c25a2aaffd5755c8f920af4834e0979cae72a474680170de2b94d06e1c
At the end of `ChainstateManager::AcceptBlock`, errors from
`FlushStateToDisk` (e.g. low disk space during pruning)
are ignored, so that callers can't mistreat a flush failure
as a block validation failure.
The internal fatal error notification still fires, so the node
will shut down on unrecoverable flush errors.
For state a dummy value is used, and the return value is ignored.
Previously the in-out `state` parameter was used, so it could
return a flush error message.
Co-authored-by: Ryan Ofsky <ryan@ofsky.org>
829255c8be cmake: Remove `SelectLibraryConfigurations` from `FindQRencode` module (Hennadii Stepanov)
5c55606da9 depends: Remove unused `lib/pkgconfig` in `qrencode` package (Hennadii Stepanov)
402ba10b20 cmake: Drop optional `PkgConfig` use in `FindQRencode` module (Hennadii Stepanov)
Pull request description:
This PR addresses:
- [this](https://github.com/bitcoin/bitcoin/pull/35602#issuecomment-4799507779) comment:
> If it works without pkg-config, then we should remove the usage of pkgconfig entirely, rather than say it will work without it, and leave the dependency in the code?
- and [this](https://github.com/bitcoin/bitcoin/pull/35602#issuecomment-4799947803) one:
> While cleaning up this module, you may also get rid of `SelectLibraryConfigurations`. We don't want that `QRencode_LIBRARY` or `QRencode_LIBRARIES` is used anywhere; there is no need to set a variable with that name.
ACKs for top commit:
purpleKarrot:
ACK 829255c8be
Tree-SHA512: fd87a5afd7c0b3271a008df8adcb2ff809053799a0658fbb5a1f15ed11f6abad25836c8e1b7507d0d4c35c027dcbba88b136ac827e17b283ee4ffbbe55d6f4ee
The result of WriteReply() losing the race condition would prevent any
new requests being read from the socket. The socket error test
sent 3 requests all at once after connecting, so in this commit
we separate the the third request to make the losing race
condition more likely, and make its effect more obvious.
Implements a child class of DynSock which is used as the mock
socket for HTTPServer unit tests. The ErrorSock::Send() method
raises a non-permanent error on the first HTTPRequest::WriteReply()
and then succeeds after the second.
In httpserver_tests.cpp use this mechanism to ensure that the
server retries a send operation if such an error is encountered,
and cover both optimistic (worker thread WriteReply()) and
non-optimistic (I/O thread SocketHandlerConnected()) send paths.
This prevents a losing race condition that could prevent the server
from reading requests from an HTTP client.
A connected socket can either be written to or read from based on the
result of GenerateWaitSockets(). That method checks the HTTPRemoteClient
flag m_send_ready. If it's `true` the implication is that there is
data in the client's send buffer ready to go. Once that data is sent
and the buffer is empty, MaybeSendBytesFromBuffer() sets it `false` again.
The sad case was when a worker thread calling WriteReply() adds
data to the send buffer, but before it sets m_send_ready to `true`,
the I/O thread sends that data and empties the buffer. With the
buffer unexpectedly empty, WriteReply() sets m_send_ready to `true`.
The effect of this is that the socket will stay in "write" mode
with nothing to write. With nothing to write, MaybeSendBytesFromBuffer()
never sets it back to `false` and the socket is stuck forever.
bbbbab86a8 ci: Bump tsan config to ubuntu:26.04 with -U_FORTIFY_SOURCE (MarcoFalke)
Pull request description:
The `-U_FORTIFY_SOURCE` should be harmless in the Tsan CI, and is required to work around https://github.com/bitcoin/bitcoin/issues/30586
ACKs for top commit:
fanquake:
ACK bbbbab86a8
Tree-SHA512: 7c4b434342861fabc52eda7b551ebe08fcde6079cd39d54a21938c88dcfd80cdb876dd7de859bac1201a2b928163c19704c24d5b5a5e76f4935e33cb3e6ae2bd
