💬 hebasto commented on pull request "cmake: add a component for each binary":
(https://github.com/bitcoin/bitcoin/pull/31844#issuecomment-2657761654)
> @stickies-v Thanks for pointing that out, that was accidental! I actually didn't notice the difference. I think we should fix it so that they're aligned instead of having a single outlier.
>
> ~Though.. would it make sense to rename the target to `libbitcoinkernel` instead of changing the component to `bitcoinkernel`? I think the former would be more obvious?~
>
> Edit: nm, can't do that as CMake will rename the resulting file to liblibbitcoinkernel.so.

But we can:
```cmake
add_cust
...

💬 furszy commented on pull request "wallet: fix rescanning inconsistency":
(https://github.com/bitcoin/bitcoin/pull/31629#issuecomment-2657775368)
After a few conversations with mzumzande, it seems to me that we could split the "scan blocks beyond the last processed block" issue into two scenarios:

(1) when the wallet mutex is locked for the entire time the rescanning process is executed. And (2) when the wallet mutex is not locked for the entire rescanning time.

(1) Is #31474 case:
Given that we set the "last processed block" to the chain tip just before calling the initial rescan. I do think this process expects to stop at the "l
...

💬 davidgumberg commented on pull request "build: Enhance Ccache performance across worktrees and build trees":
(https://github.com/bitcoin/bitcoin/pull/30861#discussion_r1955257968)
Maybe better expressed as: Is trying to both override the compiler launcher and make configure_warnings errors a use case that should be supported? If so, making this message a `configure_warning` is incompatible with #31665 since that makes `configure_warnings` fatal errors if `WCONFIGURE_ERROR=ON`.

If it is not a use case that should be supported, then making this message a configure_warning might be good together with #31665, since it would cause an error in CI if ccache ever got disabled
...

💬 l0rinc commented on pull request "Add -pruneduringinit option to temporarily use another prune target during IBD":
(https://github.com/bitcoin/bitcoin/pull/31845#discussion_r1955268028)
I meant that if we could avoid writing blocks (and especially undos, which likely don't serve any purpose during IBD as far as I can tell), we could speed up IBD measurably for pruned nodes.

If the reason for writing blocks is to avoid flushing to LevelDB, there may be better ways (as mentioned, https://github.com/bitcoin/bitcoin/pull/31645 + sorting speeds up dumping from e.g. 30 minutes to 7).

💬 sipa commented on pull request "RFC: Generated headers with ""_hex user-defined literal":
(https://github.com/bitcoin/bitcoin/pull/31861#issuecomment-2657797259)
Eh, needing `-ftemplate-depth` and `-fconstexpr-steps` sounds pretty terrible. Thank you for investigating, though.

💬 laanwj commented on pull request "random: Check `GetRNDRRS` is supported in `InitHardwareRand` to avoid infinite loop":
(https://github.com/bitcoin/bitcoin/pull/31826#issuecomment-2657812796)
> It's unclear to me under what scenario the call might fail

The [ARM documentation](https://developer.arm.com/documentation/107997/0000/AArch64-registers/AArch64-Generic-System-Control-registers-summary/RNDRRS--Reseeded-Random-Number) isn't very specific on that:

> If the hardware returns a genuine random number, PSTATE.NZCV is set to 0b0000.
>
> If the instruction cannot return a genuine random number in a reasonable period of time, PSTATE.NZCV is set to 0b0100 and the data value retur
...

✅ fjahr closed a pull request: "RFC: Generated headers with ""_hex user-defined literal"
(https://github.com/bitcoin/bitcoin/pull/31861)

💬 fjahr commented on pull request "RFC: Generated headers with ""_hex user-defined literal":
(https://github.com/bitcoin/bitcoin/pull/31861#issuecomment-2657816972)
Alright, closing ✅

👍 hebasto approved a pull request: "cmake: add a component for each binary"
(https://github.com/bitcoin/bitcoin/pull/31844#pullrequestreview-2616350801)
ACK 9b033bebb18dfd609c02736292f37cc6589fcc8d.

I have a slight preference for the approach mentioned [above](https://github.com/bitcoin/bitcoin/pull/31844#issuecomment-2657761654).

💬 laanwj commented on issue "GetRandBytes() Hangs on Samsung Galaxy S25 and OnePlus 13":
(https://github.com/bitcoin/bitcoin/issues/31817#issuecomment-2657838784)
> Build with: Android NDK 25.1.8937393 & 27.2.12479018

We've had some problems building on android (including NDK 25, see #29360), and are curious how you do the builds for that platform, for testing, can you list more specific build instructions please?

💬 ismaelsadeeq commented on pull request "cluster mempool: introduce TxGraph":
(https://github.com/bitcoin/bitcoin/pull/31363#discussion_r1955149722)
In "txgraph: (feature) make max cluster count configurable and oversize state" 370c419c330ca73d9ea44a7d48506a5c203e9c17

This is a duplicate I think

💬 ismaelsadeeq commented on pull request "cluster mempool: introduce TxGraph":
(https://github.com/bitcoin/bitcoin/pull/31363#discussion_r1955245898)
In "txgraph: (optimization) delay chunking while sub-acceptable" 30d7c8ce7f34e977238d1454dd032196cbfd936b

nit: we can have truthy/false method for this so that we can just call it.
we have this conditional statement in quite a few places

💬 ismaelsadeeq commented on pull request "cluster mempool: introduce TxGraph":
(https://github.com/bitcoin/bitcoin/pull/31363#discussion_r1955280251)
I see this now 👍🏾

💬 hugohn commented on issue "GetRandBytes() Hangs on Samsung Galaxy S25 and OnePlus 13":
(https://github.com/bitcoin/bitcoin/issues/31817#issuecomment-2657855639)
Hey @laanwj ! Our Nunchuk Android app is open source at https://github.com/nunchuk-io/nunchuk-android. You can take a look at the build instructions included in the repo. Let us know if you have any questions!

💬 laanwj commented on issue "GetRandBytes() Hangs on Samsung Galaxy S25 and OnePlus 13":
(https://github.com/bitcoin/bitcoin/issues/31817#issuecomment-2657890223)
Thanks! i'd looked there but couldn't find anything that compiles Bitcoin Core, or any C++ code for that matter.

💬 hugohn commented on issue "GetRandBytes() Hangs on Samsung Galaxy S25 and OnePlus 13":
(https://github.com/bitcoin/bitcoin/issues/31817#issuecomment-2657925768)
You need to first compile the SDK, which is a wrapper for libnunchuk (written in C++ and reuses Core code). Then publish the SDK to the local maven and include it in the app. @laanwj

https://github.com/nunchuk-io/nunchuk-android-nativesdk

💬 achow101 commented on pull request "test: check `scanning` field from `getwalletinfo`":
(https://github.com/bitcoin/bitcoin/pull/31768#issuecomment-2657972899)
ACK bb0879ddabc8b3a7253bc774d23b842937d18015

🚀 achow101 merged a pull request: "test: check `scanning` field from `getwalletinfo`"
(https://github.com/bitcoin/bitcoin/pull/31768)

👍 ryanofsky approved a pull request: "ci: build multiprocess on most jobs"
(https://github.com/bitcoin/bitcoin/pull/30975#pullrequestreview-2616515574)
Code review ACK 2d570c80ffd00b41d5232db7f8a08407cd9b36f5. The changes in the two commits now are very straightforward. It's nice to see multiprocess code running on all the CI jobs without any workarounds.

💬 ryanofsky commented on pull request "ci: build multiprocess on most jobs":
(https://github.com/bitcoin/bitcoin/pull/30975#discussion_r1955404279)
In commit "ci: build multiprocess for all depends jobs" (d937f3abdccdfdf1008dceb7a4235b1cbab9a3ae)

This is a documentation change. not really a CI change, so ideally I think it wouldn't be part of this commit.

I think the most logical place to move this change would be commit 63dffe1795d9e7b1d3307e0982dbbea2f1563f0f in followup PR #31802, because that's the commit which adds the corresponding depends setting (`NO_MULTIPROCESS ?= $(if $(findstring mingw32,$(HOST))$(findstring openbsd,$(HOST
...