💬 willcl-ark commented on pull request "test: disable secp256 tests by default":
(https://github.com/bitcoin/bitcoin/pull/32782#issuecomment-3018384728)
> As an author of that library I am uncomfortable with any usage unguarded by correctness tests. The software is sensitive to compiler errors (which can be triggered by all sorts of random environmental nonsense) and ought to be tested with the exact compiler environment used. A single predictable bit error in signing is enough to leak private keys and can happen in ways that still result in valid signatures. (e.g. miscompilation that results in the first byte/bit of the nonce being set to any s
...

✅ willcl-ark closed a pull request: "test: disable secp256 tests by default"
(https://github.com/bitcoin/bitcoin/pull/32782)

💬 TheCharlatan commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2174599172)
This is still a micro benchmark, because the input standardness check is just a tiny fraction of stuff that gets actually checked when processing a new transaction. This could probably just be deleted, or replaced with a more comprehensive check of ProcessTransaction/ProcessNewPackage.

⚠️ l0rinc opened an issue: "[IBD] Raspberry Pi: 90% CPU time for 1.5% of block processing"
(https://github.com/bitcoin/bitcoin/issues/32832)
There are numerous reports about how slow syncing on Raspberry Pi is, a few recent ones from different platforms:

* https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2977222246
> I'm running a Raspberry Pi 5 with 8GB of RAM and a 4TB SSD on RPi's Debian Lite Bookworm. This is a fresh install of v29 and after more than two weeks I'm only at blockheight of 829564 of 901531.

* https://stacker.news/items/978269
> IBD now, I am sitting at 7 days and only 78% synced. The progress has whit
...

💬 fanquake commented on pull request "build, docs: Fix Boost-related issues on NetBSD":
(https://github.com/bitcoin/bitcoin/pull/32828#issuecomment-3018550241)
> The boost-headers package does not provide CMake configuration files

Is there an upstream issue for this?

💬 dergoegge commented on pull request "[WIP] Cluster mempool implementation":
(https://github.com/bitcoin/bitcoin/pull/28676#issuecomment-3018572194)
Functional test in this commit: https://github.com/dergoegge/bitcoin/commit/6329ce979f63b396aa036a1ad39798bb83fa4ade (change to `random.cpp` is necessary to make it deterministic, without it the test only hits the assert 1/5 times)

cc @instagibbs

💬 maflcko commented on pull request "test: disable secp256 tests by default":
(https://github.com/bitcoin/bitcoin/pull/32782#issuecomment-3018586630)
For the guix cross-compiled release binaries, I don't think the secp256 tests are included at all. So testing for compiler errors is currently only done indirectly, when a CI task (or a dev) picks a compiler with a somewhat similar version string. I've opened https://github.com/bitcoin-core/packaging/pull/285 as a draft to actually test the guix-produced release binaries. However, it seems a bit tedious, and it would be easier if the release binaries would offer an extended/dev/debug build that
...

💬 TheCharlatan commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#issuecomment-3018588171)
Updated d9e030d56343bb452d86169f77ddfb64f7160235 -> 690a5dac223ed18a65c9d9e6c535466cc3ad4511 ([kernelApi_41](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_41) -> [kernelApi_42](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_42), [compare](https://github.com/TheCharlatan/bitcoin/compare/kernelApi_41..kernelApi_42))

* Addressed @stringintech's [comment](https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2173853678), using the correct name for the kernel component. This w
...

⚠️ saravadeanil reopened an issue: "[signet v22.0.0] Unable to sync node from scratch"
(https://github.com/bitcoin/bitcoin/issues/32762)
Hi, I am trying to run bitcoin signet node with below configurations:-

- Bitcore release:- `v22.0.0`

- Parameters:-

```
- '-chain=signet'
- '-rest'
- '-txindex'
- '-disablewallet'
- '-server'
- '-rpcbind=0.0.0.0'
- '-rpcport=38332'
- '-rpcallowip=0.0.0.0/0'
- '-rpcthreads=512'
- '-rpcworkqueue=4096'
- '-rpcuser=xxxxxxxxxx'
- '-rpcpassword=xxxxxxxxxx'

...

✅ saravadeanil closed an issue: "[signet v22.0.0] Unable to sync node from scratch"
(https://github.com/bitcoin/bitcoin/issues/32762)

📝 dergoegge opened a pull request: "test: Add `msgtype` to `msg_generic` slots"
(https://github.com/bitcoin/bitcoin/pull/32833)
`msg_generic` can't be used unless `msgtype` is listed in `__slots__`

Example from a [custom test](https://github.com/dergoegge/bitcoin/blob/6329ce979f63b396aa036a1ad39798bb83fa4ade/test/functional/p2p_bug28676.py):

```
2025-06-30T10:14:55.418000Z TestFramework (INFO): PRNG seed is: 3137163719543762151
2025-06-30T10:14:55.418000Z TestFramework (INFO): Initializing test directory /tmp/nix-shell-110135-0/bitcoin_func_test_7lmiemmp
2025-06-30T10:14:55.675000Z TestFramework (INFO): Setting
...

💬 maflcko commented on pull request "test: Add `msgtype` to `msg_generic` slots":
(https://github.com/bitcoin/bitcoin/pull/32833#issuecomment-3018612787)
lgtm ACK 7dc43ea503a2c145ffd4fe14b794300bfc2bcdee

Could add a small smoke test, maybe in `./test/functional/p2p_ping.py`, but seems fine either way

💬 fanquake commented on pull request "build, docs: Fix Boost-related issues on NetBSD":
(https://github.com/bitcoin/bitcoin/pull/32828#discussion_r2174748759)
This should link to the relevant issue.

💬 hebasto commented on pull request "build, docs: Fix Boost-related issues on NetBSD":
(https://github.com/bitcoin/bitcoin/pull/32828#discussion_r2174762553)
Sure! Added.

💬 Sjors commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#issuecomment-3018644831)
> `AreInputsStandard` is always called with a warm cache. The benchmark is not.

The `bench.run` call does not clear `coins`, so it's warm after the first iteration. However it's not measuring loading coins from disk. If that's only determined by the disk seek time [0], you're looking at 80 to 160 nanoseconds. My understanding is that our UTXO cache is mostly there to prevent writes, which are much slower than reads.

[0] https://en.wikipedia.org/wiki/Hard_disk_drive_performance_characterist
...

💬 maflcko commented on issue "[IBD] Raspberry Pi: 90% CPU time for 1.5% of block processing":
(https://github.com/bitcoin/bitcoin/issues/32832#issuecomment-3018646771)
> ((900000-[886157](https://mempool.space/block/00000000000000000001b658dd1120e82e66d2790811f89ede9742ada3ed6d77))/900000=1.5%)

Could clarify in the title or in the text that this is for blocks after assumevalid?

💬 hebasto commented on pull request "build, docs: Fix Boost-related issues on NetBSD":
(https://github.com/bitcoin/bitcoin/pull/32828#issuecomment-3018658040)
> > The boost-headers package does not provide CMake configuration files
>
> Is there an upstream issue for this?

I've updated the PR description.

💬 Sjors commented on pull request "p2p: add more bad ports":
(https://github.com/bitcoin/bitcoin/pull/32826#issuecomment-3018661110)
utACK 6967e8e8abbc35ac98e8e3745a8bbed56e77526f

I checked that the ports make sense.

💬 l0rinc commented on pull request "mempool: Avoid needless vtx iteration in `removeForBlock` during IBD":
(https://github.com/bitcoin/bitcoin/pull/32827#discussion_r2174789941)
That's *the* question, this is what I was referring to in the PR description:
> Draft until I get feedback on whether `MempoolTransactionsRemovedForBlock` [should still be called for empty vectors](https://github.com/bitcoin/bitcoin/pull/32730#discussion_r2140931183), given that `feature_fee_estimation` is failing if we skip it... Would be cool if we could avoid adding another callback into the validation queue...

💬 optout21 commented on pull request "mempool: Avoid needless vtx iteration in `removeForBlock` during IBD":
(https://github.com/bitcoin/bitcoin/pull/32827#discussion_r2174806312)
I think it's a different question: does it need to be called ...

1. when the mempool is empty, or
2. when the list of transactions to be removed is empty.