💬 theStack commented on issue "tracing: issue running `contrib/tracing/log_utxos.bt`":
(https://github.com/bitcoin/bitcoin/issues/33227#issuecomment-3216760599)
Couldn't reproduce this issue on my aarch64 machine (`Linux 6.16.0-21-qcom-x1e #21-Ubuntu SMP PREEMPT_DYNAMIC Sun Aug 10 00:54:48 UTC 2025 aarch64`), running Ubuntu 25.04, systemtap 5.1-4.1 and bpftrace v0.21.2.

🤔 fjahr reviewed a pull request: "index: Don't commit state in BaseIndex::Rewind"
(https://github.com/bitcoin/bitcoin/pull/33212#pullrequestreview-3147906824)
Post merge ACK a602f6fb7bf5f9e57299f4d6e246c82379fad8d2

💬 fjahr commented on pull request "index: Don't commit state in BaseIndex::Rewind":
(https://github.com/bitcoin/bitcoin/pull/33212#discussion_r2295881585)
nit: Would have been nice to give a why (e.g. something like "This ensures they are never ahead of the actual chain on restart since this would be identified as index corruption upon restart") and maybe it could also have mentioned that this is a general issue for all indexes, not coinstats-specific.

💬 sipa commented on pull request "refactor: Use typesafe Wtxid in compact block encodings":
(https://github.com/bitcoin/bitcoin/pull/29752#issuecomment-3216827263)
FWIW, having the wtxids in the vector directly here was intentional, to minimize pointer indirection and cache effects during compact block reconstruction.

It may be worth benchmarking to see if this didn't inadvertently introduced a performance regression.

💬 mzumsande commented on issue "Indexes stuck on unknown best block after unclean shutdown":
(https://github.com/bitcoin/bitcoin/issues/33208#issuecomment-3216866205)
Would be good to reopen, since this was only partly foxed, it looks like this could also happen during initial index sync, see https://github.com/bitcoin/bitcoin/pull/33212#pullrequestreview-3140857089

⚠️ fanquake reopened an issue: "Indexes stuck on unknown best block after unclean shutdown"
(https://github.com/bitcoin/bitcoin/issues/33208)
I was contacted by someone who runs a lot of nodes that they see the following issue happen very often: After an unclean shutdown an index reports that it is at an unknown best block and the node can not be restarted unless the index is deactivated or resynced.

```
2025-08-16T12:34:43Z Verification progress: 99%
2025-08-16T12:34:43Z Verification: No coin database inconsistencies in last 6 blocks (6 transactions)
2025-08-16T12:34:43Z Block index and chainstate loaded
2025-08-16T12:34:43Z Opening
...

🤔 hebasto reviewed a pull request: "Update libmultiprocess subtree to fix build issues"
(https://github.com/bitcoin/bitcoin/pull/33241#pullrequestreview-3148108782)
I've tested this branch on OpenBSD. It works [fine](https://github.com/hebasto/bitcoin-core-nightly/actions/runs/17175341417).

However, building on NetBSD remains broken: https://github.com/bitcoin-core/libmultiprocess/pull/196.

💬 ryanofsky commented on pull request "Update libmultiprocess subtree to fix build issues":
(https://github.com/bitcoin/bitcoin/pull/33241#issuecomment-3216999952)
re: https://github.com/bitcoin/bitcoin/pull/33241#issuecomment-3216370455
> failure looks real? The unit test should normally pass in a few milliseconds, so taking 40 minutes seems odd?

re: https://github.com/bitcoin/bitcoin/pull/33241#issuecomment-3216596839
> I reproduced this by repeatedly calling `mptest`. Took about 50'000 tries until it hung indefinitely.

Yes the failure is real, and this is probably issue https://github.com/bitcoin-core/libmultiprocess/issues/189, which I also rep
...

🤔 enirox001 reviewed a pull request: "test: fix p2p_leak_tx.py"
(https://github.com/bitcoin/bitcoin/pull/33121#pullrequestreview-3148172896)
Concept ACK ab43e0b on fixing the test flakiness.

I took a shot at making `test_notfound_on_unannounced_tx()` more deterministic using mocktime. Feel free to use it if helpful:

```diff
diff --git a/test/functional/p2p_leak_tx.py b/test/functional/p2p_leak_tx.py
index 3fd324a029..f50993e932 100755
--- a/test/functional/p2p_leak_tx.py
+++ b/test/functional/p2p_leak_tx.py
@@ -11,6 +11,7 @@ from test_framework.util import (
assert_equal,
)
from test_framework.wallet import MiniW
...

🚀 fanquake merged a pull request: "threading: remove ancient CRITICAL_SECTION macros"
(https://github.com/bitcoin/bitcoin/pull/32592)

💬 hebasto commented on pull request "Update libmultiprocess subtree to fix build issues":
(https://github.com/bitcoin/bitcoin/pull/33241#issuecomment-3217208986)
> > failure looks real? The unit test should normally pass in a few milliseconds, so taking 40 minutes seems odd?
>
> I reproduced this by repeatedly calling `mptest`. Took about 50'000 tries until it hung indefinitely.

Is this a newly introduced issue, or does it also exist on the master branch?

💬 ryanofsky commented on issue "intermittent timeout in mptest unit test":
(https://github.com/bitcoin/bitcoin/issues/33244#issuecomment-3217234389)
As noted https://github.com/bitcoin/bitcoin/pull/33241#issuecomment-3216999952, I'm pretty sure this is caused by https://github.com/bitcoin-core/libmultiprocess/issues/189. It's possible to reproduce the issue locally by just running mptest in a loop thousands of times until it locks up.

https://github.com/bitcoin-core/libmultiprocess/issues/189 happens because the new "disconnecting and blocking" test introduced in https://github.com/bitcoin-core/libmultiprocess/issues/160 tests for for probl
...

💬 ryanofsky commented on pull request "Update libmultiprocess subtree to fix build issues":
(https://github.com/bitcoin/bitcoin/pull/33241#issuecomment-3217235762)
> Is this a newly introduced issue, or does it also exist on the master branch?

I'm not sure if it's been seen in master but I would expect it happens in master. Seems unlikely any change in this PR would cause it, see #33244

🤔 naiyoma reviewed a pull request: "test: add option to skip large re-org test in feature_block"
(https://github.com/bitcoin/bitcoin/pull/33003#pullrequestreview-3148930871)
Tested, and `--skipreorg` successfully reduces test runtime from `60s to 35s`.
I’m not very sure about this approach — splitting was also suggested here https://github.com/bitcoin/bitcoin/issues/16613#issuecomment-548952103 I think it’s a better long-term solution and could be done in a follow-up (not sure)

📝 151henry151 opened a pull request: "build: Remove deprecated CMAKE_SKIP_BUILD_RPATH and SKIP_BUILD_RPATH settings"
(https://github.com/bitcoin/bitcoin/pull/33247)

📝 151henry151 opened a pull request: "doc: Replace FIXME placeholders with correct libblkmaker version numbers"
(https://github.com/bitcoin/bitcoin/pull/33248)
## Summary

This PR replaces FIXME placeholders in the release notes with the correct libblkmaker version numbers.

## Changes

- Replace FIXME placeholders in release notes with correct version numbers:
- `FIXME` → `0.4.2`
- `FIXME` → `0.5.1`

## Context

The release notes for version 0.10.4 contained FIXME placeholders for libblkmaker version numbers. These same version numbers are correctly specified in other release notes (e.g., 0.9.5, 0.10.0, 0.11.2) as 0.4.2 and 0.5.1.

## Testing

- [
...

💬 151henry151 commented on pull request "doc: Replace FIXME placeholders with correct libblkmaker version numbers":
(https://github.com/bitcoin/bitcoin/pull/33248#issuecomment-3217461249)
I thought this might be a worthwhile first attempt at contributing to the bitcoin core project, but it looks like the pull request was closed automatically. Can someone help me understand why, or check this out to see if that is correct?

📝 andradepsa opened a pull request: "Bitcoin 2.0: The Continuity Protocol "
(https://github.com/bitcoin/bitcoin/pull/33249)

# 🪙 Bitcoin 2.0: The Continuity Protocol
## The Future of Bitcoin: Evolution or Extinction?

> The original Bitcoin protocol is a masterpiece of engineering.
> But it contains a silent flaw, programmed into its very DNA: the inevitability of generational wealth loss.

---

## ❗ The Inevitable Crisis: Bitcoin's Great Filter

The greatest long-term threat to Bitcoin's utility is not regulation, competition, or quantum computing. It is a simple, unavoidable demographic reality:

...

⚠️ w0xlt opened an issue: "`feature_bind_extra.py` test fails in `test_runner` if new nodes are added"
(https://github.com/bitcoin/bitcoin/issues/33250)
When new nodes are added to the `feature_bind_extra.py` test, it succeeds if run individually, but fails if run via `test_runner` with the error message:

```
TestFramework (ERROR): Unexpected exception
Traceback (most recent call last):
File "/home/node/test/functional/test_framework/test_framework.py", line 191, in main
self.setup()
File "/home/node/test/functional/test_framework/test_framework.py", line 349, in setup
self.setup_network()
File "/home/node/build/test/functional/fe
...

💬 w0xlt commented on pull request "net: Prevent node from binding to the same `CService`":
(https://github.com/bitcoin/bitcoin/pull/33231#issuecomment-3217858176)
Thank you all for the review.
I completely changed the approach.

While addressing the reviews, I realized that using `std::set` to avoid duplicates doesn't solve the problem. If the options `-bind=127.0.0.1:8333 -bind=127.0.0.1:8333=onion` are present, the node will crash anyway, as one option will be allocated in the `CConnman::Options::vBinds` vector and the other in `CConnman::Options::onion_binds`.

Therefore, even after deduplicating each vector, it is still necessary to check for con
...