🤔 stratospher reviewed a pull request: "Improve LastCommonAncestor performance + add tests"
(https://github.com/bitcoin/bitcoin/pull/33515#pullrequestreview-3310200173)
ACK 3635d62f5a935801e26a0d5fa2cb5e2dbbb42f9b.

Seems to work better when there are fewer but deeper forks.

Got this when running each LCA algorithm 10,000 times on the same block pairs in the same block constellation:


- No forks - kind of same
LastCommonAncestor : 962us
NaiveLastCommonAncestor : 986us

- 0.1% forks - 18x slower
LastCommonAncestor : 1103us
NaiveLastCommonAncestor : 20481us

- 0.5% forks - 11x slower
LastCommonAncestor : 1030us
NaiveLastCommonAncestor : 11591us
...

💬 fanquake commented on pull request "[28.x] ci: Fix Qt 5.15 URL":
(https://github.com/bitcoin/bitcoin/pull/33561#issuecomment-3376996728)
ACK 2cd432dc6dad1b9f97d1c791ff1c1b0dd25a8db6

🚀 fanquake merged a pull request: "[28.x] ci: Fix Qt 5.15 URL"
(https://github.com/bitcoin/bitcoin/pull/33561)

💬 furszy commented on pull request "index: initial sync speedup, parallelize process":
(https://github.com/bitcoin/bitcoin/pull/26966#discussion_r2410734769)
> It went well thanks [0030dc5](https://github.com/bitcoin/bitcoin/commit/0030dc5ba46da402d36edd5cb32492397deeae7f)
> Sorry for hijacking the PR :)

hehe np, I owe you a few reviews anyway.

📝 fanquake opened a pull request: "[27.x] Fix Qt download URLs"
(https://github.com/bitcoin/bitcoin/pull/33564)
Backports:
* #33561
* #33563

💬 ryanofsky commented on pull request "Update libmultiprocess subtree to support reduced logging":
(https://github.com/bitcoin/bitcoin/pull/33518#issuecomment-3377126580)
<!-- begin push-2 -->
Updated 0e3fd1142c45f8feced5a4cfff3ed654e450310f -> 2e24e1c7331105ab141b3d734c19a2ccf857c293 ([`pr/subtree-6.1`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree-6.1) -> [`pr/subtree-6.2`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree-6.2), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/subtree-6.1..pr/subtree-6.2))<!-- end --> adding https://github.com/bitcoin-core/libmultiprocess/pull/222 to fix CI errors

<!-- begin push-3 -->
Updated 2e24
...

👋 ryanofsky's pull request is ready for review: "Update libmultiprocess subtree to support reduced logging"
(https://github.com/bitcoin/bitcoin/pull/33518)

💬 ryanofsky commented on pull request "Update libmultiprocess subtree in 30.x branch":
(https://github.com/bitcoin/bitcoin/pull/33519#issuecomment-3377143022)
<!-- begin push-2 -->
Updated 8c0c0bf1b078bc931965418ef9b28d176d57db0d -> ae63cc4bf2d25a5b7ce9d166aa288431e8ca16a7 ([`pr/subtree-6-v30.1`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree-6-v30.1) -> [`pr/subtree-6-v30.2`](https://github.com/ryanofsky/bitcoin/commits/pr/subtree-6-v30.2), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/subtree-6-v30.1..pr/subtree-6-v30.2))<!-- end --> adding https://github.com/bitcoin-core/libmultiprocess/pull/222 and https://github.com/bitcoin-
...

👋 ryanofsky's pull request is ready for review: "Update libmultiprocess subtree in 30.x branch"
(https://github.com/bitcoin/bitcoin/pull/33519)

💬 stringintech commented on pull request "fuzz: compact block harness":
(https://github.com/bitcoin/bitcoin/pull/33300#discussion_r2410849029)
When fuzzing on macOS (Apple Silicon), I ran into lots of crashes when copying the cached dir into the destination:

```
libc++abi: terminating due to uncaught exception of type std::__1::__fs::filesystem::filesystem_error: filesystem error: in copy_file: File exists ["/var/folders/wc/3l6l_0b92zzg54v6rmvqqn300000gn/T/test_common bitcoin/cmpctblock/6c5e38c6dcfbc2607321/regtest/blocks/xor.dat"] ["/var/folders/wc/3l6l_0b92zzg54v6rmvqqn300000gn/T/cmpctblock_cachedca12974312651650d6b0/datadir/regt
...

📝 vasild opened a pull request: "net_processing: rename RelayTransaction to better describe what it does"
(https://github.com/bitcoin/bitcoin/pull/33565)
Rename `PeerManager::RelayTransaction()` to
`PeerManager::ScheduleTxForBroadcastToAll()`. The transaction is not relayed when the method returns. It is only scheduled for broadcasting at a later time. Also, there will be another method which only schedules for broadcast to Tor or I2P peers.

---

This is part of [#29415 Broadcast own transactions only via short-lived Tor or I2P connections](https://github.com/bitcoin/bitcoin/pull/29415). Putting it in its own PR to reduce the size of #29415
...

💬 mzumsande commented on pull request "validation: Improve warnings in case of chain corruption":
(https://github.com/bitcoin/bitcoin/pull/33553#discussion_r2410894036)
done

💬 m3dwards commented on pull request "Clear out space on GHA jobs":
(https://github.com/bitcoin/bitcoin/pull/33514#issuecomment-3377259935)
I wondered if it could be sped up and it looks like deleting `/usr/local/lib/android` is what takes the time. It's 9.8gb so probably not worth skipping the deletion. I tried a few tricks like rsyncing an empty directory over it but it looks like `rm -rf` is king in terms of speed.

So I concur, perhaps best to just apply to the job that needs it.

🤔 janb84 reviewed a pull request: "validation: Improve warnings in case of chain corruption"
(https://github.com/bitcoin/bitcoin/pull/33553#pullrequestreview-3310548122)
Concept ACK

This PR introduces a informative warning for the user in the case that the users has an invalid block (header) due to corruption or otherwise.

NIT: why keep looping ? is there a path where the node can recover from this ?

partial code review ✅

<details><summary> this PR </summary>

Gives warning in case of chain corruption

```sh
2025-10-07T14:24:52Z Pre-synchronizing blockheaders, height: 266146 (~97.53%)
2025-10-07T14:24:55Z [warning] Received header for a bl
...

📝 Sjors opened a pull request: "miner: empty mempool special case for waitNext()"
(https://github.com/bitcoin/bitcoin/pull/33566)
Block template fees are calculated by looping over new_tmpl->vTxFees and return (early) once the fee_threshold is exceeded.

This left an edge case when the mempool is empty, which this commit fixes and adds a test for.

Fixes https://github.com/Sjors/sv2-tp/issues/9

💬 Sjors commented on pull request "miner: empty mempool special case for waitNext()":
(https://github.com/bitcoin/bitcoin/pull/33566#issuecomment-3377304798)
This is not worth the effort to backport imo.

💬 theuni commented on pull request "multiprocess: Fix high overhead from message logging":
(https://github.com/bitcoin/bitcoin/pull/33517#issuecomment-3377330552)
Rebased on #33518 temporarily to make sure ci is happy with everything combined.

💬 theuni commented on pull request "multiprocess: Fix high overhead from message logging":
(https://github.com/bitcoin/bitcoin/pull/33517#discussion_r2410969953)
I only did it this way because it's more readable to me that way, and because I figured there may be more logging options for us to use in the future that would make the in-place init more complicated.

Happy to change it if you feel strongly.

💬 theuni commented on pull request "multiprocess: Fix high overhead from message logging":
(https://github.com/bitcoin/bitcoin/pull/33517#discussion_r2410980251)
I'm torn about what to do here, so feedback welcome. Adding another value upstream at any point would cause a crash here. But because we don't know what that future value would be, we can't predict how we should react to it now.

Just commenting because this effectively freezes `mp::Log`, and would require adding new fields to `LogMessage` instead. I'm ok with that, but @ryanofsky might not be.

💬 Sjors commented on pull request "Update libmultiprocess subtree to support reduced logging":
(https://github.com/bitcoin/bitcoin/pull/33518#issuecomment-3377368922)
utACK eda91b07fd9f2a6af3c31659d51f51aacf8989c4

Just checked the subtree update validity. Will do some testing with #33517 and https://github.com/Sjors/sv2-tp