💬 casey commented on issue "RFC: Formal description of the RPC API":
(https://github.com/bitcoin/bitcoin/issues/29912#issuecomment-3283403636)
@achow101 I sort of lost steam, although I did take a couple of stabs at it.

[This branch](https://github.com/casey/bitcoin/tree/schema-rpc) adds a `schema` RPC which outputs a JSON description of all RPCs. You can see the output [here](https://github.com/casey/bitcoin/blob/9d90e50d191330237688eea1a4bd93018b417da2/schema.json). The format is ad-hoc.

Based on feedback that it might be preferable to use a standard format, I started on an implementation which uses JSON Schema in [this branch](ht
...

💬 pablomartin4btc commented on pull request "rpc: refactor: use string_view in Arg/MaybeArg":
(https://github.com/bitcoin/bitcoin/pull/32983#discussion_r2342778880)
not sure about the clarity of this one-liner change... perhaps could be:
```suggestion
if (auto dummy = self.MaybeArg<std::string_view>("dummy"); dummy && *dummy != "*") {
```

💬 pablomartin4btc commented on pull request "rpc: refactor: use string_view in Arg/MaybeArg":
(https://github.com/bitcoin/bitcoin/pull/32983#discussion_r2342779089)
nit: (not a blocker) if you need to re-touch...
```suggestion
if (!descriptor.empty() && !ret.empty()) {
```

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