💬 pablomartin4btc commented on pull request "rpc: refactor: use string_view in Arg/MaybeArg":
(https://github.com/bitcoin/bitcoin/pull/32983#discussion_r2342779257)
nit (for safety & consistency):
```suggestion
throw JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY, tfm::format"Unknown address type '%s'", address_type));
```

Already done in other places like:

https://github.com/bitcoin/bitcoin/blob/b49a4f17aba76d2f2d7f1109d7e68b02303947bf/src/rpc/node.cpp#L193

💬 pablomartin4btc commented on pull request "rpc: refactor: use string_view in Arg/MaybeArg":
(https://github.com/bitcoin/bitcoin/pull/32983#discussion_r2342779437)
nit (same observation here regarding `tfm::format`):
```suggestion
throw JSONRPCError(RPC_INVALID_PARAMETER, tfm::format("Invalid action '%s'", action));
```

👍 pablomartin4btc approved a pull request: "rpc: refactor: use string_view in Arg/MaybeArg"
(https://github.com/bitcoin/bitcoin/pull/32983#pullrequestreview-3214377448)
crACK & tACK b49a4f17aba76d2f2d7f1109d7e68b02303947bf

Verified addressed comments & suggestions from @maflcko since my last [review](https://github.com/bitcoin/bitcoin/pull/32983#pullrequestreview-3051797902).

Performed some manual testing on RPC calls (`getblock`, `addnode`, `getdescriptoractivity`, `signmessage`, `verifymessage`). Also tested them passing very long strings (>10MB).

Left a couple of tiny nits, none blocker.

💬 l0rinc commented on pull request "common: Make arith_uint256 trivially copyable":
(https://github.com/bitcoin/bitcoin/pull/33332#issuecomment-3283440999)
> let's run some benchmarks

I have already tested move construction in https://github.com/bitcoin/bitcoin/pull/33332#pullrequestreview-3197960566

💬 nguyenthingot1973v-spec commented on issue "把虚拟的“挖矿”货币应用到真实的实体“挖有机矿”，采用IoT设备记录真实的生产数据构成NFT，实现可追溯，不可簒改，去中心化的区块链Pi公链分布式":
(https://github.com/bitcoin/bitcoin/issues/33357#issuecomment-3283442470)
****

💬 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_r2342879651)
I had that version before, but didn't like that the small and big files made the percentages look unevenly spaced. But I have reverted that version and shuffled the files, this should make the progress feel more uniform - thank you for the observation!

💬 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_r2342880343)
Done, thanks!

💬 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_r2342882164)
What's problem would chunking solve in your opinion? I don't mind doing it, but the current version is slightly simpler and slightly faster, so I need at least *some* justification for giving up both :)

💬 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_r2342882442)
Good call, changed it back to regex matching

📝 George11Albadr opened a pull request: "Garcoin"
(https://github.com/bitcoin/bitcoin/pull/33371)
Utilizamos parámetros personalizados listos para conexion grupal de 5 nodos y ejecutamos bloque minando exactamente 20 dle garcoin. Documentación en garcoin md

✅ George11Albadr closed a pull request: "Garcoin"
(https://github.com/bitcoin/bitcoin/pull/33371)

💬 0xB10C commented on pull request "trace: Workaround GCC bug compiling with old systemtap":
(https://github.com/bitcoin/bitcoin/pull/33310#issuecomment-3284058090)
lgtm ACK 93a29ff2830162c8129d35c7b9beb43fab984503

The change in Systemtap can be found here: https://sourceware.org/git/?p=systemtap.git;a=blobdiff;f=includes/sys/sdt.h;h=28d236d91cd8e4d3a5db8b13cac90fb678c629cf;hp=9ecb1cb6fed2bbb9f58aaca640c5840e471b67ac;hb=34facf7ee6b43dae66cc109973a4eda42e439163;hpb=2c11a115bdbe41a7f064ccd32b41c76c5b7c516d

Including this makes sense as there are likely some OSs (e.g. [Ubuntu 22.04](https://launchpad.net/ubuntu/jammy/+source/systemtap)) still shipping <s
...

💬 ryanofsky commented on pull request "multiprocess: Don't require bitcoin -m argument when IPC options are used":
(https://github.com/bitcoin/bitcoin/pull/33229#discussion_r2343457313)
re: https://github.com/bitcoin/bitcoin/pull/33229#discussion_r2336547527

I think instead of expanding this PR I'm inclined to keep the first commit minimal and limited to (1) adding binary name to `bitcoind -version` and `bitcoin-node -version` output so the test can work, and (2) returning the right binary names from `interfaces::Init::exeName()` methods.

There are a few related followups that would be nice to make but aren't needed by this PR:

1. Updating QT `-version` output so it in
...

🚀 fanquake merged a pull request: "ci: always use tag for LLVM checkout"
(https://github.com/bitcoin/bitcoin/pull/33364)

✅ fanquake closed an issue: "ci: derived LLVM version too new"
(https://github.com/bitcoin/bitcoin/issues/33345)

💬 davidgumberg commented on pull request "common: Make arith_uint256 trivially copyable":
(https://github.com/bitcoin/bitcoin/pull/33332#issuecomment-3284350163)
> > let's run some benchmarks
>
> I have already tested move construction in [#33332 (review)](https://github.com/bitcoin/bitcoin/pull/33332#pullrequestreview-3197960566)

As I understand it, `std::move()` does not force the invocation of a move assignment / constructor, it casts its argument to an `rvalue` but if a constructor / assignment operator that takes an rvalue reference is not found, a function that takes an lvalue will be used, so in the `ArithUint256MoveCircle` benchmark, the co
...

💬 fanquake commented on pull request "ci: always use tag for LLVM checkout":
(https://github.com/bitcoin/bitcoin/pull/33364#issuecomment-3284351724)
Backported to 30.x in #33356.

💬 fanquake commented on pull request "ci: use Mold linker for asan-lsan-ubsan-integer-no-depends-usdt workflow":
(https://github.com/bitcoin/bitcoin/pull/33370#issuecomment-3284429177)
These changes should be in `00_setup_env_native_asan.sh`.

💬 nervana21 commented on issue "RFC: Formal description of the RPC API":
(https://github.com/bitcoin/bitcoin/issues/29912#issuecomment-3284438240)
I’m using the output from @casey’s `schema` RPC in a [project](https://github.com/nervana21/bitcoin-rpc-codegen) that generates Rust clients across versions of Core.

Because my project depends upon it, I'm maintaining a [branch](https://github.com/nervana21/bitcoin/tree/2025-07-schema-generation) with casey's patch applied.

If there’s interest in reviving this, I can help keep the output in sync with Core.

📝 Sjors opened a pull request: "mining: log failed blocks in submitSolution()"
(https://github.com/bitcoin/bitcoin/pull/33372)
Unlike the submitblock RPC which takes a fully serialized block, when a block solution is received via IPC the client only provides the nonce, coinbase and a few other fields to `submitSolution()`. It may not have all the information it needs to reconstruct the block. This makes debugging difficult when the block is invalid.

This commit therefore logs the fully serialized block if it's rejected. This is in addition to the failure reason logged by `ProcessNewBlock()`.

Example on a custom si
...