💬 cedwies commented on pull request "Revert compact block cache inefficiencies":
(https://github.com/bitcoin/bitcoin/pull/33253#issuecomment-3233243613)
code-review ACK b7b249d

Read-through + local bench; results match others which I have seen. This PR restores cache locality in the compact-block reconstruction hot path and adds a well focused benchmark.

* Reverts the “vector of `CTransactionRef`” refactors and restores a cache-friendly layout for reconstruction.
* `InitData` again takes `std::vector<std::pair<Wtxid, CTransactionRef>> extra_txn`, causing the wtxid to be available without dereferencing in the hot loop.
* Early-exit and c
...

⚠️ 0xB10C opened an issue: "signet: disk-space-DoS due to low mining difficulty"
(https://github.com/bitcoin/bitcoin/issues/33266)
Due to low mining difficulty on Signet, an attacker can grind all possible nonces of a block header and create valid[^valid], alternative headers for Signet blocks. Since these have the [same chain work](https://github.com/bitcoin/bitcoin/blob/6ca6f3b37b992591726bd13b494369bee3bd6468/src/validation.cpp#L4416) as the tip, the newly mined headers [can](https://github.com/bitcoin/bitcoin/blob/6ca6f3b37b992591726bd13b494369bee3bd6468/src/validation.cpp#L4435) be submitted along with the original blo
...

💬 kevkevinpal commented on pull request "threading: reduce the scope of lock in getblocktemplate":
(https://github.com/bitcoin/bitcoin/pull/33264#discussion_r2307302790)
Makes sense to me! updated in [493ba0f](https://github.com/bitcoin/bitcoin/pull/33264/commits/493ba0f688311280056491986068cd4a9ad2be66)

⚠️ lnxsrt opened an issue: "124th peer connection closed every second"
(https://github.com/bitcoin/bitcoin/issues/33267)
### Is there an existing issue for this?

- [x] I have searched the existing issues

### Current behaviour

I'm on Bitcoin Core v29.0.0

I noticed that when at the max number of peers (124 total; 10 outbound; 114 inbound) the most recent peer connection is continually dropped after 1 second and another peer is selected. I can't imagine this is good behavior for the network.

As you can see, my peer count is very high (basically == number of seconds I've been at 124 peers) and the most recent pee
...

💬 instagibbs commented on issue "Zero output not cleared":
(https://github.com/bitcoin/bitcoin/issues/33265#issuecomment-3233461032)
thanks, hit me up when you reproduce it; I am having trouble disintangling if the issue is P2A, or ephemeral dust, or something else.

💬 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.