💬 0xB10C commented on pull request "tracing: fix invalid argument in mempool_monitor":
(https://github.com/bitcoin/bitcoin/pull/32454#issuecomment-2865366915)
Code Review ACK 31c5ebc4007884b655f2f90ca09e36e0b9ada4da

Seems like I introduced that bug in https://github.com/bitcoin/bitcoin/pull/31848 (ec47ba349d0b3cb2d274593ca7b828ae70584e10).

💬 polespinasa commented on pull request "tests: Expand HTTP coverage to assert libevent behavior":
(https://github.com/bitcoin/bitcoin/pull/32408#discussion_r2081079062)
I'm not sure about this but shouldn't this be `socket.timeout`? As we're using `sock.recv` and not `getresponse()`?

🤔 polespinasa reviewed a pull request: "tests: Expand HTTP coverage to assert libevent behavior"
(https://github.com/bitcoin/bitcoin/pull/32408#pullrequestreview-2827278739)
tACK 840dd5b6eb0b2c1f35a91c36acac5d97933172dc

Maybe the three commits could be squashed?

💬 polespinasa commented on pull request "tests: Expand HTTP coverage to assert libevent behavior":
(https://github.com/bitcoin/bitcoin/pull/32408#discussion_r2081097699)
If the timeout is set to 2 wouldn't make more sense to test between 2 and 4 seconds? Can it be less than 2 seconds?

💬 hMsats commented on issue "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2865489117)
@fanquake Thanks a lot! I expected something like this (debug info) but thought it was some compiler option. The `strip` worked and now my bitcoind is only 12 MB 👍. As I never used `strip` on `bitcoin-28.0` I don't expect this to make a difference but will try it first on my server anyway or could it?

This is very confusing. I'm a long time bitcoin node runner and linux user but would never have thought of this possibility. **Shouldn't this be mentioned in the `doc/build-unix.md`?**

⚠️ hodlinator opened an issue: "qa: Failure in wallet_basic.py spendzeroconfchange test"
(https://github.com/bitcoin/bitcoin/issues/32456)
CI failure upon merge of my PR (ad5cd129f3cc72f2d2b140e182781bf3bb5dbacc): https://github.com/bitcoin/bitcoin/actions/runs/14916001314/job/41901630172

Relevant high-level log:
```
22/267 - wallet_basic.py failed, Duration: 23 s

stdout:
2025-05-08T21:04:47.763000Z TestFramework (INFO): PRNG seed is: 1820560705145373934
2025-05-08T21:04:47.764000Z TestFramework (INFO): Initializing test directory /Users/runner/work/bitcoin/bitcoin/ci/scratch/test_runner/test_runner_₿_🏃_20250508_210317/wallet_ba
...

💬 vasild commented on pull request "multiprocess: Add bitcoin wrapper executable":
(https://github.com/bitcoin/bitcoin/pull/31375#discussion_r2081139299)
> `bitcoin daemon -daemon`

Good point. Indeed I find that super not-intuitive, I did not think about that before. I would strongly prefer to rename it to `node`, e.g. `bitcoin node -daemon`.

> `bitcoind -daemon` already means the same thing

Eh, but somehow I don't find it so perplexing. Or even if it is as confusing, now we have a chance to pick better names.

💬 hebasto commented on pull request "depends: Avoid using helper variables in toolchain file":
(https://github.com/bitcoin/bitcoin/pull/31360#issuecomment-2865541704)
My Guix build:
```
aarch64
cab0e4d3d2602d2eaa8893ae5294bd736b514fea6deb72df03c4d693971282dd guix-build-7343a1846ceb/output/aarch64-linux-gnu/SHA256SUMS.part
21163373fc74e834f3d81309888fc4cd99719462be8fef447e535fb56aa5ce1e guix-build-7343a1846ceb/output/aarch64-linux-gnu/bitcoin-7343a1846ceb-aarch64-linux-gnu-debug.tar.gz
b09ca7a33bf16d3e97bce8800bf57a06402a9cf4860d327be3d6571a56be598c guix-build-7343a1846ceb/output/aarch64-linux-gnu/bitcoin-7343a1846ceb-aarch64-linux-gnu.tar.gz
f1b2aa3e
...

💬 maflcko commented on issue "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2865595699)
What are your settings?

Can you share the debug log?

Can you run with the debug categories `bench, blockstorage, lock, prune, validation`, and possibly `rpc`, if there is a background caller?

🚀 fanquake merged a pull request: "tracing: fix invalid argument in mempool_monitor"
(https://github.com/bitcoin/bitcoin/pull/32454)

💬 hMsats commented on issue "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2865633695)
@maflcko I will but it will take some time as I'm on vacation right now but will investigate when I have time.

Created `bitcoind` via:

`cmake -B build -DWITH_ZMQ=ON -DBUILD_GUI=ON`

Settings (same as for 28.0):

```
txindex=1
rpcthreads=4
rpcworkqueue=64
dbcache=2500
maxconnections=100
permitbaremultisig=0
datacarrier=0
```

💬 fanquake commented on pull request "tracing: fix invalid argument in mempool_monitor":
(https://github.com/bitcoin/bitcoin/pull/32454#issuecomment-2865654520)
Backported to `29.x` in #32292.

💬 l0rinc commented on issue "qa: Failure in wallet_basic.py spendzeroconfchange test":
(https://github.com/bitcoin/bitcoin/issues/32456#issuecomment-2865716098)
I can't reproduce it either on my Mac - but it does seem to be passing with latest push at least.

<img width="549" alt="Image" src="https://github.com/user-attachments/assets/30b441f9-a8d0-44ff-b23c-2529a7de424a" />

💬 maflcko commented on pull request "build: let CMake determine the year":
(https://github.com/bitcoin/bitcoin/pull/32445#issuecomment-2865717510)
Not sure if this is worth it. Currently 4 lines of code need to be changed, looking at b537a2c02a9921235d1ecf8c3c7dc1836ec68131. After this, 3 lines will need to be changed. I don't really see the benefit here.

Whereas this comes with downsides:

* People compiling an ancient EOL version/commit will get the impression that they are running a recent release from the current year. This could lead them to thinking they have the latest security patches.
* Conversely, people setting a fixed, bu
...

💬 captCovalent commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2865777515)
In addition to my post above.

Concept NACK!

At this point, it’s clear that this PR lacks support across many parts of the community. Moving forward despite the current sentiment would cause significant reputational harm to Bitcoin Core. I strongly urge you not to proceed.

The way this proposal has been managed raises concerns about transparency and corruption. Rather than imposing new limitations, we should be enhancing configurability. Satoshi’s vision depends on honest, autonomous nodes—no
...

💬 fanquake commented on pull request "build: let CMake determine the year":
(https://github.com/bitcoin/bitcoin/pull/32445#issuecomment-2865786971)
> the behavior just seems more confusing than before for users.

Note that historically we've produced release binaries that have misleading dates:
```bash
Bitcoin Core version v26.1.0
Copyright (C) 2009-2023 The Bitcoin Core developers
```
`26.1` was released in April of 2024: https://github.com/bitcoin/bitcoin/releases/tag/v26.1/. I think `28.1` was the first time we've ever backported a date bump.

> user-facing version numbers or year numbers should just be removed,

As I said abo
...

📝 l0rinc opened a pull request: "bench: replace benchmark block with more representative one (413567 → 784588)"
(https://github.com/bitcoin/bitcoin/pull/32457)
#### Summary
This PR replaces our benchmark's reference block with one that's more modern and representative of current usage patterns.

### Context
The [current benchmark block](https://mempool.space/block/413567) was mined in 2016 and added in PR #9049. Since it predates many modern script types, our benchmarks don't accurately reflect current network conditions.

### Suggestion
We're replacing it with [block 784588](https://mempool.space/block/784588) from 2023, which provides a better
...

💬 maflcko commented on pull request "build: let CMake determine the year":
(https://github.com/bitcoin/bitcoin/pull/32445#issuecomment-2865854548)
> ... 2023 ... `26.1` was released in April of 2024: https://github.com/bitcoin/bitcoin/releases/tag/v26.1/. I think `28.1` was the first time we've ever backported a date bump.

Personally I think it is fine to not bump them for release branches (It is a bit like the Ubuntu release 24.04.2 happening in '25). However, it is also fine to bump the year along with the version. `CMakeLists.txt` will have to be touched anyway for a point release (several times), so touching one line at most once mo
...

💬 Sjors commented on pull request "doc: warn that CheckBlock() underestimates sigops":
(https://github.com/bitcoin/bitcoin/pull/31624#discussion_r2081342307)
I don't think it's useful at all, given the historical context. But I don't feel confident enough about dropping it either. That's why I added the historical context in the commit message, so someone else in the future can try dropping it.

💬 Sjors commented on pull request "doc: warn that CheckBlock() underestimates sigops":
(https://github.com/bitcoin/bitcoin/pull/31624#issuecomment-2865918066)
> Combining the two in same PR might be better to not miss writing the follow-up.

Could just open an issue to track it?