✅ willcl-ark closed an issue: "RFC: hosting utxo snapshot on bitcoincore.org and linking to it"
(https://github.com/bitcoin/bitcoin/issues/31972)

💬 willcl-ark commented on issue "RFC: hosting utxo snapshot on bitcoincore.org and linking to it":
(https://github.com/bitcoin/bitcoin/issues/31972#issuecomment-3427285688)
This is being discussed on the website repo.

💬 l0rinc commented on pull request "validation: fetch block inputs on parallel threads >10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#issuecomment-3427287178)
I love the new structure, it's a lot easier to track the progress compared to previous versions. It's also measurably faster than previous versions, we seem to be nearing ~20% - sweeeet! It also pairs well with other `Siphash` related changes that are in the pipeline.

I have reimplemented most of it locally to make sure I can do a meaningful review, see https://github.com/l0rinc/bitcoin/pull/47 for my attempt. It's not finished, I'm still experimenting with different alternatives to make sure
...

💬 stickies-v commented on issue "RFC: hosting utxo snapshot on bitcoincore.org and linking to it":
(https://github.com/bitcoin/bitcoin/issues/31972#issuecomment-3427293529)
See https://github.com/bitcoin-core/bitcoincore.org/issues/1130 for the discussion.

✅ willcl-ark closed an issue: "assumeutxo: not syncing the snapshot chainstate"
(https://github.com/bitcoin/bitcoin/issues/30971)

💬 willcl-ark commented on issue "assumeutxo: not syncing the snapshot chainstate":
(https://github.com/bitcoin/bitcoin/issues/30971#issuecomment-3427299987)
Since the problem isn’t easily reproducible, I’m closing this for now. If it occurs again, please feel free to open a new issue or comment here so we can reopen it.

✅ willcl-ark closed an issue: "[RFC] What security expectations does/should the RPC server have from credentialed RPC clients?"
(https://github.com/bitcoin/bitcoin/issues/32274)

💬 davidgumberg commented on pull request "docs: clarify RPC credentials security boundary":
(https://github.com/bitcoin/bitcoin/pull/33196#issuecomment-3427324550)
ACK 433954b

💬 supertestnet commented on issue "Allow creating and injecting a custom coinbase into a block template":
(https://github.com/bitcoin/bitcoin/issues/28475#issuecomment-3427329409)
I think it's mostly superseded by this PR anyway: https://github.com/bitcoin/bitcoin/pull/32468

💬 furszy commented on pull request "index: initial sync speedup, parallelize process":
(https://github.com/bitcoin/bitcoin/pull/26966#issuecomment-3427331772)
Small update, per discussion, will push the thread pool on an isolated PR in the coming week. Replacing the current http server `WorkQueue` and all its related code; it is an easy dedup that adds further test coverage to a never unit nor fuzz tested area. Plus a way to start using this class in the repo that allow others to use it.

Also, I'm investigating the tx index slow down with @andrewtoth. Trying to understand the differences between us. Worst-case scenario, we can disable parallel sync
...

💬 willcl-ark commented on issue "TSAN/MSAN fails with vm.mmap_rnd_bits=32 even with llvm 18.1.3":
(https://github.com/bitcoin/bitcoin/issues/30674#issuecomment-3427339037)
Please update the CI readme.md with the needed info, thanks.

💬 maflcko commented on issue "TSAN/MSAN fails with vm.mmap_rnd_bits=32 even with llvm 18.1.3":
(https://github.com/bitcoin/bitcoin/issues/30674#issuecomment-3427342678)
for reference, the workaround isn't needed for the GHA runners, but it is needed locally and for the Cirrus runners, see also the workflow yaml: https://github.com/bitcoin/bitcoin/blob/c862936d16a640690ef4c89456738fe4bb99be54/.github/workflows/ci.yml#L554-L557

✅ willcl-ark closed an issue: "v27.2 guix build fails with hash mismatch"
(https://github.com/bitcoin/bitcoin/issues/31266)

💬 willcl-ark commented on issue "v27.2 guix build fails with hash mismatch":
(https://github.com/bitcoin/bitcoin/issues/31266#issuecomment-3427345542)
This issue is being closed because it falls outside the scope of this repository.

💬 maflcko commented on issue "v27.2 guix build fails with hash mismatch":
(https://github.com/bitcoin/bitcoin/issues/31266#issuecomment-3427350747)
> This issue is being closed because it falls outside the scope of this repository.

Not sure this is fully true, but this will be fixed by the next time-machine bump. C.f. https://github.com/bitcoin/bitcoin/pull/33185

💬 dergoegge commented on pull request "ci: add Valgrind fuzz":
(https://github.com/bitcoin/bitcoin/pull/33461#issuecomment-3427415276)
ACK c020ae082664438cf340cb196fc5bd0d31ed810f

I think it'd be good to have this in CI (for the rare case where it does find something).

📝 fanquake reopened a pull request: "ci: add Valgrind fuzz"
(https://github.com/bitcoin/bitcoin/pull/33461)
Valgrind fuzz runtime?

🤔 stringintech reviewed a pull request: "kernel: Introduce C header API"
(https://github.com/bitcoin/bitcoin/pull/30595#pullrequestreview-3360113563)
Comments on logging support (c5f8bd0e).

💬 stringintech commented on pull request "kernel: Introduce C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2447818262)
I guess we want to throw if `StartLogging()` returns `false` (and let the `catch` block to handle the cleanup and re-throw)?
Side question: Can `StartLogging()` itself actually throw? If not, this part can be simplified further.
```suggestion
try {
// Only start logging if we just added the connection.
if (LogInstance().NumConnections() == 1 && !LogInstance().StartLogging()) {
throw std::runtime_error("Failed to start logging");

...

💬 stringintech commented on pull request "kernel: Introduce C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2447802589)
For `btck_logging_connection_create()` we are documenting that we return null on error. But it seems we either return a connection or crash here. Shouldn't we catch the exception here and return null?