💬 willcl-ark commented on pull request "[30.x] Backports":
(https://github.com/bitcoin/bitcoin/pull/33609#issuecomment-3596972244)
Backports all look good to me.

We are missing a release note for https://github.com/bitcoin/bitcoin/pull/33229 currently, I think it's one worth adding too.

📝 kevkevinpal opened a pull request: "refactor/p2p: Decouple CNode from PeerManagerImpl::MaybeDiscourageAndDisconnect"
(https://github.com/bitcoin/bitcoin/pull/33983)
## Description
Refactor MaybeDiscourageAndDisconnect to accept individual parameters (`has_no_ban`, `is_manual`, `is_local_addr`, `is_inbound_onion`, `peer_addr`) instead of taking a CNode& reference directly.

This decouples the function from CNode while preserving all original logic paths and behavior.

This change is just a refactor, so no tests were modified

## Linked issue
This is a part of #33958.
Let me know if this is not needed and I can close this PR

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >40% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2577433809)
> when a block has e.g. a double-spend to make sure it's not propagated to the main cache

That would be a necessary condition of a double-spending block test. If the double spend is propagated to the main cache it is part of the utxo set and the test is a failure. The main cache is treated as the source of truth.

⚠️ mbarulli opened an issue: "When 30.0 for Start9"
(https://github.com/bitcoin/bitcoin/issues/33984)
### Please describe the feature you'd like to see added.

Just a reminder that people running Core on Start9 machines are still on 29.2.
When is 30.0 going to be packaged for [Start9](https://start9.com/)?
Thanks!

### Is your feature related to a problem, if so please describe it.

_No response_

### Describe the solution you'd like

_No response_

### Describe any alternatives you've considered

_No response_

### Please leave any additional context

_No response_

✅ willcl-ark closed an issue: "When 30.0 for Start9"
(https://github.com/bitcoin/bitcoin/issues/33984)

💬 willcl-ark commented on issue "When 30.0 for Start9":
(https://github.com/bitcoin/bitcoin/issues/33984#issuecomment-3597046249)
@mbarulli this is out of scope for this project.

I think the correct place to open such an issue would be in the Start9 repo.

https://github.com/Start9Labs

👍 brunoerg approved a pull request: "wallet: warn against accidental unsafe older() import"
(https://github.com/bitcoin/bitcoin/pull/33135#pullrequestreview-3525526629)
reACK 189437a3dedefce3945ab2a8c05785eb283c2c6f

🤔 dergoegge reviewed a pull request: "refactor/p2p: Decouple CNode from PeerManagerImpl::MaybeDiscourageAndDisconnect"
(https://github.com/bitcoin/bitcoin/pull/33983#pullrequestreview-3525544018)
In my opinion this is too fine grained of a step and not worth a PR on its own, as it will cause more churn down the line (e.g. the signature of `MaybeDiscourageAndDisconnect` will likely have to change again).

💬 dergoegge commented on pull request "refactor/p2p: Decouple CNode from PeerManagerImpl::MaybeDiscourageAndDisconnect":
(https://github.com/bitcoin/bitcoin/pull/33983#discussion_r2577510113)
This should not be removed

📝 instagibbs opened a pull request: "fuzz: gate mempool entry based on weight"
(https://github.com/bitcoin/bitcoin/pull/33985)
The mempool implementation now uses TxGraph with entries using FeePerWeight, not vsize. This means our package_rbf harness will erroneously add more transaction weight than we can support inside of FeeFrac. Gate more aggressivelt using WITNESS_SCALE_FACTOR.

Fixes https://github.com/bitcoin/bitcoin/issues/33981

💬 kevkevinpal commented on pull request "refactor/p2p: Decouple CNode from PeerManagerImpl::MaybeDiscourageAndDisconnect":
(https://github.com/bitcoin/bitcoin/pull/33983#issuecomment-3597170872)
> In my opinion this is too fine grained of a step and not worth a PR on its own, as it will cause more churn down the line (e.g. the signature of `MaybeDiscourageAndDisconnect` will likely have to change again).

Gotcha, should I attempt to decouple more/all functions in `PeerManagerImpl`. I was worried about attempting to make too large a PR, but I guess I went the other extreme, haha

💬 instagibbs commented on issue "integer overflow in FUZZ=package_rbf":
(https://github.com/bitcoin/bitcoin/issues/33981#issuecomment-3597171676)
I believe I diagnosed it and implemented a fix https://github.com/bitcoin/bitcoin/pull/33985

💬 kevkevinpal commented on pull request "refactor/p2p: Decouple CNode from PeerManagerImpl::MaybeDiscourageAndDisconnect":
(https://github.com/bitcoin/bitcoin/pull/33983#discussion_r2577556376)
I added a `should_disconnect` parameter and after this function is called we do the following

```
if (should_disconnect) {
pto->fDisconnect = true;
}
return true;
```

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >40% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2577565765)
But `ConnectBlock` also inserts the newly created utxos into the cache, so that the next call to `AccessCoin` will just get it from the cache's `cacheCoins` map.

💬 maflcko commented on pull request "refactor/p2p: Decouple CNode from PeerManagerImpl::MaybeDiscourageAndDisconnect":
(https://github.com/bitcoin/bitcoin/pull/33983#issuecomment-3597201044)
Can you explain this a bit better?

> An (ugly) initial POC can be seen here: https://github.com/theuni/bitcoin/tree/multiprocess_p2p. Note that it will likely not be rebased because it was not intended to be used as-is. Instead, chunks will be extracted and PR'd separately.

Did you cherry-pick a commit from this branch? If not, why not? If yes, why did the author change?

💬 instagibbs commented on pull request "fuzz: gate mempool entry based on weight":
(https://github.com/bitcoin/bitcoin/pull/33985#issuecomment-3597202152)
cc @sdaftuar

💬 l0rinc commented on issue "When 30.0 for Start9":
(https://github.com/bitcoin/bitcoin/issues/33984#issuecomment-3597240774)
please see: https://x.com/start9labs/status/1981503274051391495

💬 mbarulli commented on issue "When 30.0 for Start9":
(https://github.com/bitcoin/bitcoin/issues/33984#issuecomment-3597261243)
Thanks! Very useful tip!


On Mon, Dec 1, 2025, 16:36 l0rinc ***@***.***> wrote:

> *l0rinc* left a comment (bitcoin/bitcoin#33984)
> <https://github.com/bitcoin/bitcoin/issues/33984#issuecomment-3597240774>
>
> please see: https://x.com/start9labs/status/1981503274051391495
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/bitcoin/bitcoin/issues/33984#issuecomment-3597240774>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAILWGX
...

🤔 janb84 reviewed a pull request: "refactor: C++20 operators"
(https://github.com/bitcoin/bitcoin/pull/33771#pullrequestreview-3525686869)
ACK 48840bfc2d7beeac0ddf56a3c26b243156ec8936

Reducing custom handwritten boilerplate and replacing it with modern idioms is not something we should shun to do (imho). Using the spaceship operation `<=>` will use the compiler to generate the other operators correctly.

Was a bit worried that the spaceship did not yet land on apple clang, given the [documentation](https://developer.apple.com/xcode/cpp/)
<img width="761" height="383" alt="Screenshot 2025-12-01 at 15 42 16" src="https://githu
...

✅ kevkevinpal closed a pull request: "refactor/p2p: Decouple CNode from PeerManagerImpl::MaybeDiscourageAndDisconnect"
(https://github.com/bitcoin/bitcoin/pull/33983)

💬 kevkevinpal commented on pull request "refactor/p2p: Decouple CNode from PeerManagerImpl::MaybeDiscourageAndDisconnect":
(https://github.com/bitcoin/bitcoin/pull/33983#issuecomment-3597265384)
> Can you explain this a bit better?
>
> > An (ugly) initial POC can be seen here: https://github.com/theuni/bitcoin/tree/multiprocess_p2p. Note that it will likely not be rebased because it was not intended to be used as-is. Instead, chunks will be extracted and PR'd separately.
>
> Did you cherry-pick a commit from this branch? If not, why not? If yes, why did the author change?

I did not cherry-pick commits from this branch but now looking at it, I prefer the approach here instead. W
...