💬 stickies-v commented on pull request "threading: reduce the scope of lock in getblocktemplate":
(https://github.com/bitcoin/bitcoin/pull/33264#issuecomment-3233506955)
re-ACK 493ba0f688311280056491986068cd4a9ad2be66

👍 instagibbs approved a pull request: "Revert compact block cache inefficiencies"
(https://github.com/bitcoin/bitcoin/pull/33253#pullrequestreview-3164846536)
ACK b7b249d3adfbd3c7b0c4d0499a86300f57982972

non-blocking nits only

💬 instagibbs commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2307403366)
micro-nit: annotate numbered args

💬 instagibbs commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2307403840)
micro-nit: annotate numbered args

💬 instagibbs commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2307403680)
micro-nit: annotate numbered args

💬 instagibbs commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#discussion_r2307415897)
```Suggestion
// a reasonably large mempool of 50k txs, ~10MB total plus variable extra txns
```

💬 0xB10C commented on issue "124th peer connection closed every second":
(https://github.com/bitcoin/bitcoin/issues/33267#issuecomment-3233540722)
This is likely normal behavior and not a bug. What you are seeing is Bitcoin Core's inbound connection eviction in action. When a new inbound connection comes in, another connection may be closed in favor of it. This avoids an attacker filling all of your inbound connections in an attempt to eclipse you from the network. The inbound eviction algorithm takes care to protect certain peers from being disconnected - you can find details [here](https://github.com/bitcoin/bitcoin/blob/6ca6f3b37b992591
...

✅ maflcko closed an issue: "124th peer connection closed every second"
(https://github.com/bitcoin/bitcoin/issues/33267)

💬 maflcko commented on pull request "threading: reduce the scope of lock in getblocktemplate":
(https://github.com/bitcoin/bitcoin/pull/33264#issuecomment-3233577995)
lgtm ACK 493ba0f688311280056491986068cd4a9ad2be66

💬 maflcko commented on pull request "rpc: followups for 33106":
(https://github.com/bitcoin/bitcoin/pull/33189#issuecomment-3233640990)
Could remove the outdated comment as well, after 3eab8b724044dc321f70e5eed66b149713158a04?

```diff
diff --git a/test/functional/test_framework/mempool_util.py b/test/functional/test_framework/mempool_util.py
index 9ffd934f5a..3c4609c0b4 100644
--- a/test/functional/test_framework/mempool_util.py
+++ b/test/functional/test_framework/mempool_util.py
@@ -57,8 +57,7 @@ def fill_mempool(test_framework, node, *, tx_sync_fun=None):
"""Fill mempool until eviction.

Allows for simpl
...

🤔 naiyoma reviewed a pull request: "net: Prevent node from binding to the same `CService`"
(https://github.com/bitcoin/bitcoin/pull/33231#pullrequestreview-3165086159)
Concept ACK

Tested with these 3 options:

- `./build/bin/bitcoind -bind=0.0.0.0=onion -bind=0.0.0.0=onion`
- `./build/bin/bitcoind -bind=0.0.0.0 -bind=0.0.0.0 `
- `./build/bin/bitcoind -whitebind=relay@127.0.0.1:8333 -whitebind=mempool@127.0.0.1:8333`


<details>
<summary>bitcoind shuts down after the error</summary>
[error] Duplicate binding configuration for address 0.0.0.0:8334. Please check your -bind, -whitebind, and onion binding settings.
Error: Duplicate binding configurati
...

💬 jsarenik commented on issue "Zero output not cleared":
(https://github.com/bitcoin/bitcoin/issues/33265#issuecomment-3233911050)
The linked transactions ([...4628](https://mempool.space/signet/tx/a7b388a8f48350f92f8987d45409723bf329519816eba808de59ad6ebe974628) and [...34f5](https://mempool.space/signet/tx/92246e21897116e7e7b9afc62034caaadb75ae61c441c52df4a66dbdd9e234f5)) in annotated raw:

```
VERSION: 03000000
FLAG: 0001
INPUTS: 01
0c571f65a11a383eb53896d93be77cccaa979234a7c93b1cbde63d82fde01b57 01000000 00 00000000 #I-0
OUTPUTS: 03 #0..2
e803000000000000 22 5120db7b995709b105a12719e1b4d92ab4bb616805fe0e2aee2db4b86efb
...

💬 cedwies commented on pull request "net: Prevent node from binding to the same `CService`":
(https://github.com/bitcoin/bitcoin/pull/33231#discussion_r2307958813)
Was not yet able to reproduce the continuation. But just to clarify, @l0rinc : are we talking about a late-fail with “afterglow” or does the node truly keep running?

💬 stickies-v commented on pull request "ci: Migrate CI to hosted Cirrus Runners":
(https://github.com/bitcoin/bitcoin/pull/32989#issuecomment-3234213191)
Concept ACK. Price seems reasonable for the benefits, and we we're not locking ourselves in too much.

💬 ajtowns commented on pull request "rpc: followups for 33106":
(https://github.com/bitcoin/bitcoin/pull/33189#issuecomment-3234222327)
> "33106" refers to the pull request with that number: #33106, which is also linked in the PR description (only 12 times). It's common practice to link to a related PR like this (e.g. for a followup) in the PR title.

Can we please make this not common practice anymore? Memorising PR numbers is no fun. "Followups for min fee changes" would have been fine.

💬 ajtowns commented on pull request "rpc: followups for 33106":
(https://github.com/bitcoin/bitcoin/pull/33189#discussion_r2307996095)
`-> Test -incrementalrelayfee=100.00000000sat/kvB...` doesn't seem very useful indeed.

mining_basic reports `-> Test -blockmintxfee=0.00000500 (500 sat/kvB)...` which seems strictly better, as it gives a value that can actually be used with the config param as well as a sats figure?

💬 ajtowns commented on pull request "rpc: followups for 33106":
(https://github.com/bitcoin/bitcoin/pull/33189#issuecomment-3234248084)
ACK daa40a3ff97346face9dcc64564010a66c91ccb2 ; cursory review, seems reasonable

💬 jsarenik commented on issue "Zero output not cleared":
(https://github.com/bitcoin/bitcoin/issues/33265#issuecomment-3234271437)
From observation the important thing triggering the leftover (but spent, i.e. unusable) zero output inside a read-only descriptor wallet seem to be the two outputs to two different addresses in the final spend transaction. See https://mempool.space/signet/tx/af914f3f337bc84910d1d2d5d14556e5c2b07372ea99078d15c7a74c77c0b0e7?mode=details

Also see https://signet257.bublina.eu.org/sffrest.txt which may contain such transactions in the end of its output:

<img width="1080" height="1674" alt="Image" s
...

💬 l0rinc commented on pull request "[IBD] coins: increase default UTXO flush batch size to 32 MiB":
(https://github.com/bitcoin/bitcoin/pull/31645#issuecomment-3234329502)
Thanks a lot for testing this @hodlinator and @Eunovo.

It seems that different configurations behave differently here, so I've retested a few scenarios on a few different platforms to understand what the performance increase depends on exactly. It's not even a linear speedup (i.e. sometimes 32 MiB is faster, sometimes it's 64 MiB), some `dbcache` values reliably produce a lot faster results, while others reliably produce slower results for the same config (i.e. the before-after-plot for diffe
...

💬 maflcko commented on pull request "ci: Migrate CI to hosted Cirrus Runners":
(https://github.com/bitcoin/bitcoin/pull/32989#issuecomment-3234350722)
Also, would be nice to have a pull request for https://github.com/bitcoin-core/qa-assets prepared. Possibly without caching is fine, if the msan-fuzz task fits in the GHA timeout.