🚀 glozow merged a pull request: "test: add functional test for `TestShell` (matching doc example)"
(https://github.com/bitcoin/bitcoin/pull/33546)

💬 davidgumberg commented on pull request "p2p: Drop unsolicited CMPCTBLOCK from non-HB peer":
(https://github.com/bitcoin/bitcoin/pull/32606#issuecomment-3457245344)
> one race condition we might hit is a compact block being sent to our node before that peer receives the message un-selecting them as a hb peer.

In this case we probably are OK to drop, even though it wastes a little bandwidth, and for the time that our `SENDCMPCT` is on the wire to our new high-bandwidth peer, we are down to only 2 HB peers.

We'll only unselect a peer as high bandwidth when [selecting another](https://github.com/bitcoin/bitcoin/blob/24434c1284b84e2c33cf3240ca677d77cad298
...

💬 andrewtoth commented on pull request "http: replace WorkQueue and single threads handling for ThreadPool":
(https://github.com/bitcoin/bitcoin/pull/33689#discussion_r2470161972)
I see. Then perhaps more directly:
```suggestion
// Note: m_interrupt must be guarded by m_mutex, and cannot be replaced by an unguarded atomic bool.
```

✅ achow101 closed an issue: "Cannot import descriptors with label and internal:false"
(https://github.com/bitcoin/bitcoin/issues/32376)

🤔 ryanofsky reviewed a pull request: "refactor: Add util::Result failure values, multiple error and warning messages"
(https://github.com/bitcoin/bitcoin/pull/25665#pullrequestreview-3388968746)
<!-- begin push-67 -->
Updated 8b892d41fdeb5756fd83f6050f27a170338d260a -> 90b6a005d20ee6375beea1e685c35f265f6829c1 ([`pr/bresult2.66`](https://github.com/ryanofsky/bitcoin/commits/pr/bresult2.66) -> [`pr/bresult2.67`](https://github.com/ryanofsky/bitcoin/commits/pr/bresult2.67), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/bresult2.66..pr/bresult2.67))<!-- end --> fixing typos and reverting unneeded wallet change

💬 ryanofsky commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r2469805979)
re: https://github.com/bitcoin/bitcoin/pull/25665#discussion_r2454523296

> nit: Does this change to the wallet belong in this commit?

Nice catch. Dropped this change. I assume this change was necessary at some point but it no longer seems to be. (For reference this change was in commit f142cc48c7e67a2414f30487e2b9c58e868e2b23)

💬 ryanofsky commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r2469713813)
re: https://github.com/bitcoin/bitcoin/pull/25665#discussion_r2454538331

This is an interesting idea because you are right that basically everywhere the `Update()` method is used here and in follow-up PRs (#25722 and #29700), result state rarely goes from failure->success.

There is one place it happens in this PR though: when a failed LoadChainstate operation is [retried](https://github.com/ryanofsky/bitcoin/blob/8b892d41fdeb5756fd83f6050f27a170338d260a/src/init.cpp#L1753-L1758).

We cou
...

💬 dergoegge commented on pull request "Remove unnecessary seed from chainparams.cpp":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3457355840)
ACK 9c3291ff9bd713e1a92dae2c388a83e4a107bf7e

Don't think a lot of damage can be done by controlling just one of the seeds but it's just a matter of time before Luke pulls some random shenanigans.

💬 pinheadmz commented on pull request "Remove unnecessary seed from chainparams.cpp":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3457377979)
> Don't think a lot of damage can be done by controlling just one of the seeds but it's just a matter of time before Luke pulls some random shenanigans.

This is going to be a hard thread to moderate because personal attacks are forbidden, but this is one of the very few lines of code that literally point to a specific central entity.

The PR author is also a first-time contributor to the project and I'm worried this PR is going to get brigaded by people susceptible to social media influence
...

👍 stickies-v approved a pull request: "Remove unnecessary seed from chainparams.cpp"
(https://github.com/bitcoin/bitcoin/pull/33723#pullrequestreview-3389712658)
ACK 9c3291ff9bd713e1a92dae2c388a83e4a107bf7e

Operators of DNS seeds have a (limited) ability to be harmful to users, e.g. by filtering results or logging requests. Luke has shown multiple cases of hostile and unpredictable behaviour towards the Bitcoin Core project, so removing this seed seems like the responsible thing to do, even if we can't guarantee the reliability of other DNS seeds.

💬 l0rinc commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2470247644)
Originally we flushed, so if we still want to, we may want to extend this to assert that behavior. Or avoid flushing and simplify the bench. Or add the flushing behavior above to a test, etc.

💬 pinheadmz commented on pull request "Remove unnecessary seed from chainparams.cpp":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3457396673)
I think it is far more mature to wait until the service becomes unreliable or violates a stated policy rule before removing. Otherwise the project is merely reacting preemptively to someone's tweets.

💬 l0rinc commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2470254148)
Even consensus invalid ones? Or did I misunderstand the context here?

💬 l0rinc commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2470260510)
Yeah, but we want to understand where the differences are coming from, otherwise we'd have the "faster-on-my-machine" syndrome. If you disagree, just resolve the issue.

💬 dergoegge commented on pull request "Remove unnecessary seed from chainparams.cpp":
(https://github.com/bitcoin/bitcoin/pull/33723#issuecomment-3457411161)
> "must be run by entities which have some minimum level of trust within the Bitcoin community"

Can only speak for myself but that doesn't reflect my current sentiment regarding Luke.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2470278073)
We avoid flushing now.

💬 maflcko commented on issue "GetSerializeSize's return type should not be platform dependent":
(https://github.com/bitcoin/bitcoin/issues/33709#issuecomment-3457434288)
> ... LLM-generated. I'm not sure how to go about that. I am not comfortable with the idea of an LLM making changes to consensus-critical code. On the other hand, if the code is correct just closing the PR seems inappropriate.

I looked at the PR, and while it appears "correct", it is randomly only changing `size_t` to `uint64_t` in half the places, even if they are on adjacent lines (https://github.com/bitcoin/bitcoin/pull/33712/files#diff-a9bf14cec48b76a03a785de76b8bc71c5db17d494c7f02c29dfde26
...

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#discussion_r2470280988)
Yeah, InputFetcher doesn't know if a block is consensus valid or not yet. It hasn't passed `ConnectBlock` yet before entering here.

💬 darosior commented on pull request "refactor: Return uint64_t from GetSerializeSize":
(https://github.com/bitcoin/bitcoin/pull/33724#issuecomment-3457444677)
Concept ACK.

💬 brunoerg commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#discussion_r2470293205)
Perfect, I wasn't aware of `UpdateModifiedFee`, I just took a look and this is a saturated addition, so it won't have any effect. This can be ignored.