💬 pracakjarenthom777-cell commented on pull request "rpc: add target to getmininginfo field and show next block info":
(https://github.com/bitcoin/bitcoin/pull/31583#issuecomment-3336053592)
bf7996cbc3becf329d8b1cd2f1007fec9b3a3188

💬 achow101 commented on pull request "rpc: addpeeraddress: throw on invalid IP":
(https://github.com/bitcoin/bitcoin/pull/33430#issuecomment-3336143980)
ACK 316a0c513278d53cb25f42ea502d20691962aad6

🚀 achow101 merged a pull request: "rpc: addpeeraddress: throw on invalid IP"
(https://github.com/bitcoin/bitcoin/pull/33430)

💬 RandyMcMillan commented on pull request "rpcconsole: display signet challenge":
(https://github.com/bitcoin-core/gui/pull/896#issuecomment-3336239941)
fixed typo and commit scope
add Network Name formatting per @pablomartin4btc feed back
Challenge Copy&Paste-able from gui per @luke-jr feed back
Detect Default signet_challenge and display "Default"

💬 RandyMcMillan commented on pull request "rpcconsole: display signet challenge":
(https://github.com/bitcoin-core/gui/pull/896#issuecomment-3336242136)
tooltip displays challenge (even if obfuscated in rpcconsole)
<img width="970" height="690" alt="Screenshot 2025-09-25 at 7 25 34 PM" src="https://github.com/user-attachments/assets/a2a12f56-8468-4373-bfdd-40c2b5ae909d" />

💬 RandyMcMillan commented on pull request "rpcconsole: display signet challenge":
(https://github.com/bitcoin-core/gui/pull/896#issuecomment-3336245069)
when default signet_challenge detected:
<img width="1376" height="623" alt="Screenshot 2025-09-25 at 7 23 29 PM" src="https://github.com/user-attachments/assets/d2a0cd88-5585-4762-a028-d61980b72a20" />

💬 RandyMcMillan commented on pull request "rpcconsole: display signet challenge":
(https://github.com/bitcoin-core/gui/pull/896#issuecomment-3336247945)
when common length signet_challenge:

<img width="1396" height="566" alt="Screenshot 2025-09-25 at 7 22 52 PM" src="https://github.com/user-attachments/assets/866e0fe5-de31-4a80-815b-e3281272c4bf" />

💬 l0rinc commented on pull request "[IBD] coins: increase default UTXO flush batch size to 32 MiB":
(https://github.com/bitcoin/bitcoin/pull/31645#issuecomment-3336254681)
Now that we have built-in support for querying total memory, I wonder if the batch size should depend on that or if we should just bump it to constant 32 (as proposed currently). Given how messy it was to measure even this one reliably, it's likely best to leave it a constant.
But maybe we can still keep the 64 MiB version (which performed best), now that excessive dbcache already warns. Feedback is welcome.

💬 RandyMcMillan commented on pull request "rpcconsole: display signet challenge":
(https://github.com/bitcoin-core/gui/pull/896#discussion_r2380542865)
squash later

💬 RandyMcMillan commented on pull request "rpcconsole: display signet challenge":
(https://github.com/bitcoin-core/gui/pull/896#discussion_r2380543001)
squash laster

💬 RandyMcMillan commented on pull request "rpcconsole: display signet challenge":
(https://github.com/bitcoin-core/gui/pull/896#discussion_r2380545359)
maybe a global constant?

💬 RandyMcMillan commented on pull request "rpcconsole: display signet challenge":
(https://github.com/bitcoin-core/gui/pull/896#discussion_r2380554457)
the full challenge should be copy and pasted - please test
cc: @luke-jr @pablomartin4btc

💬 polespinasa commented on pull request "rpc: generateblock to allow multiple outputs":
(https://github.com/bitcoin/bitcoin/pull/32468#issuecomment-3336297423)
Rebased on top of master (after #33230 was merged).

The diff is simple:
```diff
diff --git a/src/rpc/client.cpp b/src/rpc/client.cpp
index 320823b1c1..acbdc14db8 100644
--- a/src/rpc/client.cpp
+++ b/src/rpc/client.cpp
@@ -37,7 +37,7 @@ static const CRPCConvertParam vRPCConvertParams[] =
{ "generatetoaddress", 2, "maxtries" },
{ "generatetodescriptor", 0, "num_blocks" },
{ "generatetodescriptor", 2, "maxtries" },
- //{ "generateblock", 0, "outputs"},
+ { "gener
...

💬 151henry151 commented on pull request "build: Remove CMAKE_SKIP_BUILD_RPATH and SKIP_BUILD_RPATH settings":
(https://github.com/bitcoin/bitcoin/pull/33247#issuecomment-3336328151)
> Please amend the comments in `contrib/guix/libexec/build.sh` as noted above.

I've made the recommended amendments, thanks for the guidance.

💬 davidgumberg commented on pull request "wallet: Fix relative path backup during migration.":
(https://github.com/bitcoin/bitcoin/pull/32273#discussion_r2380613802)
I can't recall if this was discussed elsewhere, but in some cases when the path ends in a relative specifier the parent directory name can't be recovered without filesystem access: e.g. the wallet name is `../`, I think filesystem access might be necessary here.

💬 ryanofsky commented on pull request "wallet: Fix relative path backup during migration.":
(https://github.com/bitcoin/bitcoin/pull/32273#discussion_r2380631535)
It was discussed, see https://github.com/bitcoin/bitcoin/pull/32273#pullrequestreview-2983599593:

> I don't think this is true. If a wallet ascends more than it descends like `../../../../mywallet`, the suggested change would use "mywallet" as the prefix. If the path contains `.` components or internal `..`, `lexically_normal` will strip them out. If the path contains trailing slashes, the suggested code strips them out to. If the path is literally just `..` or `../..` or similar even that is
...

💬 davidgumberg commented on pull request "wallet: Fix relative path backup during migration.":
(https://github.com/bitcoin/bitcoin/pull/32273#discussion_r2380642390)
I agree, maybe I had too strict of an idea of what the expectation would be for the destination of the backup: if the only goal is that the backup filename be safe and likely to work, then `lexically_normal()` is fine, and satisfying those requirements is probably good enough for the migration backup, but I'm still not sure I understand what is wrong with using the filesystem here.

💬 l0rinc commented on pull request "RFC: blocks: add `-reobfuscate-blocks` arg to xor existing blk/rev on startup":
(https://github.com/bitcoin/bitcoin/pull/33324#discussion_r2380772877)
I have pushed a new version (rebased, extended test), let me know what you think.

I have implemented a very simple multithreaded version but I couldn't convince it to achieve *any* speedup whatsoever - I guess xor operations are a lot cheaper than disk reads/writes. The total CPU usage was at 20% even with 50 threads.

I have pushed my threaded solution to [l0rinc/bitcoin@`fb75395` (#40)](https://github.com/l0rinc/bitcoin/pull/40/commits/fb75395c2164c043b8696a43b9d116d953f90800#diff-b1e1919
...

✅ amishhaa closed a pull request: "contrib: fix for macOS deployment build failing on Qt translations even though it is optional."
(https://github.com/bitcoin/bitcoin/pull/33358)

📝 amishhaa opened a pull request: "contrib: fix for macOS deployment build failing on Qt translations even though it is optional."
(https://github.com/bitcoin/bitcoin/pull/33482)
From what I deciphered reading the line https://github.com/bitcoin/bitcoin/blob/master/contrib/macdeploy/macdeployqtplus#L390 is that qt translations are optional to have hence we should be able to build without it but the case where the flag translations_dir falls back to its default Null value it raises this error.
I have moved the code which adds language files under the if statement that first checks if the value of the flag is not Null before referencing it.
This PR assumes that having Qt
...