💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >40% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2577369275)
If we have a backing cache that blocks, how can we know if it's the main thread or worker threads that need to be blocked? And if we block the main thread by mistake, it will make no progress even though the worker thread can fetch all inputs

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >40% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2577376037)
We want to specifically test that we do not access the main cache's backing view, by e.g. calling `GetCoin` on it. If we return a nullopt here then it would correctly go to the db layer, while we want to make sure we blow up here because it is a failed test.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >40% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2577394394)
> NoAccessCoinsView is designed to abort on access

It is designed to abort on accessing the db via the main cache. We want to access the db only via our `m_db` ref and not go through the main cache's `base` pointer. This is unrelated to the test of short txid collisions. For those, we want to go to successfully go to disk on the main thread, while getting a nullopt from our m_input coin.

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