💬 kristapsk commented on issue "RPC wont bind without an IP address on a non-localhost interface":
(https://github.com/bitcoin/bitcoin/issues/13155#issuecomment-3225810421)
Noticed this when there is only IPv6 address assigned to eth0 interface (lo has both 127.0.0.1 and ::1). When IPv4 address is also added to eth0, problem disappears.

```
Bitcoin Core version v29.0.0 (release build)
Using the 'arm_shani(1way,2way)' SHA256 implementation
Startup time: 2025-08-26T21:30:01Z
Default data directory /.bitcoin
Using data directory /ssd/bitcoind/mainnet
Config file: /home/bitcoind/mainnet.conf
Config file arg: chain="main"
Config file arg: datadir="/ssd/bitcoind/mainnet
...

💬 achow101 commented on issue "integer sanitizer warning, when running with -natpmp=1 enabled":
(https://github.com/bitcoin/bitcoin/issues/33245#issuecomment-3225829239)
It looks like this is being triggered by a `NLMSG_DONE` message and is something that we could avoid by checking `hdr->nlmsg_type` before doing `NLMSG_DATA` and `RTM_PAYLOAD`. This could be included in #32159 since that's already touching this code.

💬 achow101 commented on pull request "net, pcp: handle multi-part responses and filter for default route while querying default gateway":
(https://github.com/bitcoin/bitcoin/pull/32159#discussion_r2302222710)
These could be moved after `if (hdr->nlmsg_type == NLMSG_DONE) {` to avoid the integer sanitizer warning in #33245

📝 polespinasa opened a pull request: "rpc, logging: add backgroundvalidation to getblockchaininfo"
(https://github.com/bitcoin/bitcoin/pull/33259)
`getblockchaininfo` returns `verificationprogress=1` and `initialblockdownload=false` even if there's background validation.
This PR adds information about background validation to rpc `getblockchaininfo` in a similar way to `validationprogress` does.

If assume utxo was used the output of a "sync" node performing background validation:
```
$ ./build/bin/bitcoin-cli getblockchaininfo
...
"mediantime": 1756245019,
"verificationprogress": 1,
"initialblockdownload": false,
"backgr
...

💬 achow101 commented on issue "tracing: test `interface_usdt_net.py` fails due to garbage message type in `net:outbound_message` tracepoint":
(https://github.com/bitcoin/bitcoin/issues/33246#issuecomment-3226064329)
I'm able to reproduce this with a release build, but not a debug build.

💬 l0rinc commented on pull request "bench: Add more realistic Coin Selection Bench":
(https://github.com/bitcoin/bitcoin/pull/33160#discussion_r2302109933)
we don't actually need the wallet here, right?

💬 l0rinc commented on pull request "bench: Add more realistic Coin Selection Bench":
(https://github.com/bitcoin/bitcoin/pull/33160#discussion_r2302150941)
we want deterministic randomness for benchmarks, otherwise it's hard to know what we're actually measuring:
```suggestion
FastRandomContext rand{/*fDeterministic=*/true};
```

💬 l0rinc commented on pull request "bench: Add more realistic Coin Selection Bench":
(https://github.com/bitcoin/bitcoin/pull/33160#discussion_r2302152030)
we could reserve this to avoid the build failure:
```C++
std::vector<CAmount> targets;
targets.reserve(10);
for (size_t i{0}; i < targets.capacity(); ++i) {
targets.push_back(rand_range(rng, 0.1_btc, 1_btc));
}
```
Note that I have reduced the target count to 10 since the benchmark was very slow otherwise

🤔 l0rinc requested changes to a pull request: "bench: Add more realistic Coin Selection Bench"
(https://github.com/bitcoin/bitcoin/pull/33160#pullrequestreview-3157264436)
Concept ACK, the existing test were all quite trivial compared to this new one.
I left a ton of comments, for simplicity here's the final code that I'm suggesting, feel free to pick and choose from it.

<details>
<summary>Details</summary>

```C++
// Copyright (c) 2012-2022 The Bitcoin Core developers
// Distributed under the MIT software license, see the accompanying
// file COPYING or http://www.opensource.org/licenses/mit-license.php.

#include <bench/bench.h>
#include <consensus/
...

💬 l0rinc commented on pull request "bench: Add more realistic Coin Selection Bench":
(https://github.com/bitcoin/bitcoin/pull/33160#discussion_r2302156688)
I'd avoid the `Narrow No-Break Space` chars from docs if possible, they're rendered differently on different mediums

💬 l0rinc commented on pull request "bench: Add more realistic Coin Selection Bench":
(https://github.com/bitcoin/bitcoin/pull/33160#discussion_r2302174002)
Please rebase, `spendable` was removed since: https://github.com/bitcoin/bitcoin/commit/6a7aa015747e2634fe5a4b2f7fa0d104eb75c796#diff-38f1a8db124a979cb6dd76ce263f7aae0053d6967ee909e6356115fa0402dc8cL78

💬 l0rinc commented on pull request "bench: Add more realistic Coin Selection Bench":
(https://github.com/bitcoin/bitcoin/pull/33160#discussion_r2302160133)
Same, seems simpler to just leave it to deterministic instead of hard-coding a confusing seed
```suggestion
FastRandomContext det_rand{/*fDeterministic=*/true};
```

note: can we reuse this for the random source below as well?

💬 l0rinc commented on pull request "bench: Add more realistic Coin Selection Bench":
(https://github.com/bitcoin/bitcoin/pull/33160#discussion_r2302166150)
we could dedup considerable here for better signal-to-noise ratio - it's a lot of work to find the differences between the values:
```C++
const auto txout{wtx->tx->vout.at(0)};
const int input_bytes{CalculateMaximumSignedInputSize(txout, &wallet, /*coin_control=*/nullptr)};
const COutput output{(COutPoint{wtx->GetHash(), 0}), txout, /*depth=*/6 * 24, input_bytes, /*solvable=*/true, /*safe=*/true, wtx->GetTxTime(), /*from_me=*/true, /*fees=*/0};
if (int y{rng.randrange(100)}; y < 35) {

...

💬 l0rinc commented on pull request "bench: Add more realistic Coin Selection Bench":
(https://github.com/bitcoin/bitcoin/pull/33160#discussion_r2302187694)
nit: since you're also mentioning the minimum in the comment first, we might as well put the fixed size first here
```suggestion
targets.push_back(10'000'000 + det_rand.randrange(90'000'000));
```

Alternatively, to avoid all the 0s, consider:
```suggestion
targets.push_back(COIN / 10 + rng.randrange(COIN / 9 * 10));
```
This would unify it with the rest of the usages.

---

this has come up multiple times, we should really add a `randrange` helper with min/max value
...

💬 l0rinc commented on pull request "bench: Add more realistic Coin Selection Bench":
(https://github.com/bitcoin/bitcoin/pull/33160#discussion_r2302195389)
`nInput` should be `uint32_t` otherwise we'd have a narrowing conversion in `OutPoint{tx.GetHash(), nInput}`

👍 davidgumberg approved a pull request: "Revert compact block cache inefficiencies"
(https://github.com/bitcoin/bitcoin/pull/33253#pullrequestreview-3157177236)
crACK b7b249d3adfbd3c

This PR reverts two performance regressions that broke cache locality of the wtxid's we need to hash during compact block reconstruction and it adds a nice benchmark that demonstrates the regressions and might have caught them before they were merged.

For more context: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2025-08-23#1755938803-1755950270;

I reviewed the code changes here directly, and I also compared them to the commits they claimed to be reverting, a
...

💬 davidgumberg commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2302199451)
+1

💬 davidgumberg commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2302369266)
nit:

```suggestion
bench.unit("block").run([&] {
```

and maybe:

```suggestion
bench.unit("block").timeUnit(1ms, "ms").run([&] {
```

💬 davidgumberg commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2302045141)
What makes this section not performance critical, is that we're likely going to have to do a full round-trip anyways to get the collided transactions, but I still think the suggestion is more correct/consistent, so might be nice to do if retouching. Out of scope, but we can also remove the first clause of the `if` check entirely, since it's checking the inverse of the `if` block above.

💬 ajtowns commented on pull request "refactor: Use typesafe Wtxid in compact block encodings":
(https://github.com/bitcoin/bitcoin/pull/29752#issuecomment-3226578153)
(`vExtraTxnForCompact` are additional txs to what's in the mempool; `CTxMemPool::txns_randomized` is what could be removed if there wasn't a performance regression)