👋 Sjors's pull request is ready for review: "mining: add applySolution() to interface"
(https://github.com/bitcoin/bitcoin/pull/33374)

💬 Sjors commented on pull request "mining: add applySolution() to interface":
(https://github.com/bitcoin/bitcoin/pull/33374#issuecomment-3302000477)
Rebased after https://github.com/bitcoin/bitcoin/pull/33380 landed.

🚀 fanquake merged a pull request: "net: do not apply whitelist permissions to onion inbounds"
(https://github.com/bitcoin/bitcoin/pull/33395)

🚀 fanquake merged a pull request: "cmake: Install `bitcoin` manpage"
(https://github.com/bitcoin/bitcoin/pull/33407)

💬 fanquake commented on pull request "cmake: Install `bitcoin` manpage":
(https://github.com/bitcoin/bitcoin/pull/33407#issuecomment-3302015181)
Backported to 30.x in #33356.

💬 0xB10C commented on pull request "policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee":
(https://github.com/bitcoin/bitcoin/pull/33106#issuecomment-3302024332)
Here's an update of the compact block reconstruction stats from https://github.com/bitcoin/bitcoin/pull/33106#issuecomment-3155627414:

I updated node bob to a recent master that includes this PR (#33106) on 2025-08-22. It didn’t have existing sub-1 sat/vbyte transactions in it’s mempool and thus took a few days before the reconstruction rate improved. Besides the bad reconstruction performance on 2025-09-06, 2025-09-07, and 2025-09-08, it performed significantly better.

<img width="1093" h
...

💬 TheCharlatan commented on pull request "validation: fetch block inputs on parallel threads 10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#issuecomment-3302056248)
What's the status here?

📝 fanquake opened a pull request: "ci: re-add Valgrind job to the CI"
(https://github.com/bitcoin/bitcoin/pull/33411)

📝 fanquake converted_to_draft a pull request: "ci: re-add Valgrind job to the CI"
(https://github.com/bitcoin/bitcoin/pull/33411)

💬 musaHaruna commented on pull request "rpc: add scan_utxoset option to getbalance(s) to verify wallet balance accuracy":
(https://github.com/bitcoin/bitcoin/pull/33392#issuecomment-3302123151)
> Maybe run some benchmarks on the utxo set scan and full rescan and add them to the PR here. I don't have a good feeling for what the relation is and this might influence what reviewers think is better concerning running a full rescan automatically or just returning a warning/hint from `importdescriptors`.

I will run some benchmarks on both utxo set scan and full rescan, update the whole PR to use the new approach you suggested i.e to add the feature on `importdescriptors` directly, which I
...

👋 fanquake's pull request is ready for review: "ci: re-add Valgrind job to the CI"
(https://github.com/bitcoin/bitcoin/pull/33411)

📝 fanquake converted_to_draft a pull request: "ci: re-add Valgrind job to the CI"
(https://github.com/bitcoin/bitcoin/pull/33411)

📝 ryanofsky opened a pull request: " Update libmultiprocess subtree to fix intermittent mptest hang"
(https://github.com/bitcoin/bitcoin/pull/33412)
Includes:

- https://github.com/bitcoin-core/libmultiprocess/pull/207
- https://github.com/bitcoin-core/libmultiprocess/pull/208
- https://github.com/bitcoin-core/libmultiprocess/pull/211
- https://github.com/bitcoin-core/libmultiprocess/pull/201

The last change fixes the test hang reported https://github.com/bitcoin/bitcoin/issues/33244

The changes can be verified by running `test/lint/git-subtree-check.sh src/ipc/libmultiprocess` as described in [developer notes](https://github.com/
...

💬 danielabrozzoni commented on pull request "coins: warn on oversized `-dbcache`":
(https://github.com/bitcoin/bitcoin/pull/33333#discussion_r2355023220)
> The max value is only validated on 64 bits, since it's not unreasonable for 32 bits to have max memory, but on 64 bits it's likely an error.

This wasn’t immediately clear to me :) Maybe add that sentence to the commit message to make it clearer.

💬 fanquake commented on pull request "ci: re-add Valgrind job to the CI":
(https://github.com/bitcoin/bitcoin/pull/33411#issuecomment-3302327390)
The runtime isn't too bad, and it's just blown out by `wallet_miniscript.py`, which is ~4 times slower than the next slowest running test (`signet_miner.py`):
```bash
tool_signet_miner.py | ✓ Passed | 536 s
wallet_miniscript.py | ✓ Passed | 2086 s
```

💬 ismaelsadeeq commented on issue "RFC: Bitcoin Core Node `BlockTemplateManager`":
(https://github.com/bitcoin/bitcoin/issues/33389#issuecomment-3302349836)
> Overall, notion of a shared cache seems useful. In terms of the implementation approach, I think it'd be nice if new code were integrated with existing code sooner rather than later (for example if waitNext could call this in the same PR it was introduced, or if this could be used to replace static BlockAssembler variables) to avoid having duplicate functionality, and make sure the new code is well tested and the interface is practically useful

I will be working on polishing the branch and op
...

💬 fanquake commented on issue "Slow unit tests delay functional tests and leave CPU unused":
(https://github.com/bitcoin/bitcoin/issues/32770#issuecomment-3302352281)
> Same for wallet_miniscript.py in the functional tests. Under Valgrind, it is the slowest test by at least 2x any other test.

Seems to be ~4 times slower than the next slowest test: https://github.com/bitcoin/bitcoin/pull/33411#issuecomment-3302327390.

⚠️ nerses-asaturyan opened an issue: "Support Multiple OP_RETURNs or Raise OP_RETURN Limit"
(https://github.com/bitcoin/bitcoin/issues/33413)
### Please describe the feature you'd like to see added.

Bitcoin currently restricts transactions to a single OP_RETURN output of 80 bytes. This is too limiting for practical use cases like cross-chain swaps and DeFi, where OP_RETURN serves as a lightweight log (e.g. destination token addresses, proofs, parameters).

The restriction also creates inequality: miners with custom policies already accept multiple or larger OP_RETURNs, while standard users cannot. This is similar to MEV and reduces n
...

💬 TheCharlatan commented on pull request "coins: warn on oversized `-dbcache`":
(https://github.com/bitcoin/bitcoin/pull/33333#discussion_r2355054943)
Mmh, I'm not sure about this check, wouldn't it make more sense to check that it measures something at all, i.e. is greater than 0?

📝 vasild opened a pull request: "tor: enable PoW defenses for automatically created hidden services"
(https://github.com/bitcoin/bitcoin/pull/33414)
Enable [PoW defenses](https://tpo.pages.torproject.net/onion-services/ecosystem/technology/security/pow/) for hidden services that we create via Tor Control using the [`ADD_ONION` command](https://spec.torproject.org/control-spec/commands.html#add_onion).

The ability to do that has been added in [tor-0.4.9.2-alpha](https://gitlab.torproject.org/tpo/core/tor/-/commit/02c18044464bfe45f168b55297a785244094cfd5). Previous versions return a syntax error to the `ADD_ONION` command with `PoWDefensesE
...

💬 fanquake commented on pull request "ci: re-add Valgrind job to the CI":
(https://github.com/bitcoin/bitcoin/pull/33411#issuecomment-3302417796)
With `wallet_miniscript` skipped, this finishes faster than the ASAN job, and ~roughly the same time as msan & fuzzer.