💬 darosior commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2174579276)
Added a comment, thanks.

💬 darosior commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#issuecomment-3018377738)
@Sjors `AreInputsStandard` is always called with a warm cache. The benchmark is not. Additional `AccessCoin` calls to fetch coins from the cache do not introduce any meaningful cost.

@Sjors @l0rinc please let's avoid rushing to performance conclusions on the basis of a microbenchmark that is not representative of how functions are actually used in reality. This PR does not introduce any meaningful slowdown.

💬 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.