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

💬 fanquake commented on issue "oss-fuzz: build failing":
(https://github.com/bitcoin/bitcoin/issues/33366#issuecomment-3284518541)
https://github.com/google/oss-fuzz/pull/13987

💬 fanquake commented on pull request "ci: Skip Centos job on GHA runners":
(https://github.com/bitcoin/bitcoin/pull/33365#issuecomment-3284546897)
To be clear, this will start skipping the job in https://github.com/bitcoin-core/gui ?

💬 ajtowns commented on pull request "mining: log failed blocks in submitSolution()":
(https://github.com/bitcoin/bitcoin/pull/33372#issuecomment-3284604377)
> On mainnet this would be a huge message, but the IPC connection is trusted.

If this is for IPC, wouldn't it make more sense to return the value over IPC as part of an error response? Otherwise, having it be a LogDebug or even LogTrace seems more sensible?

💬 Sjors commented on pull request "mining: log failed blocks in submitSolution()":
(https://github.com/bitcoin/bitcoin/pull/33372#issuecomment-3284678151)
@ajtowns currently the return value is a boolean. I could indeed change it to return both a boolean and a string. But ideally I'd like to back port this to v30, so keeping it as simple as possible without changing the interface.

I picked `LogInfo` because, especially on mainnet, the information seems critical enough to log by default.

💬 stickies-v commented on pull request "rpc: refactor: use string_view in Arg/MaybeArg":
(https://github.com/bitcoin/bitcoin/pull/32983#discussion_r2343793451)
Will do if I force-push, but they are aliases so there should be no safety difference, and afaik the project also hasn't stated a preference to phase one out, although I personally tend to use and prefer `tfm::format`.

💬 stickies-v commented on pull request "rpc: refactor: use string_view in Arg/MaybeArg":
(https://github.com/bitcoin/bitcoin/pull/32983#discussion_r2343800487)
Yeah you're probably right, will change if I force push, but I feel like this is close to merge and the PR has been open for a while so gonna minimize nit force pushes. Thanks for your review!

🚀 fanquake merged a pull request: "trace: Workaround GCC bug compiling with old systemtap"
(https://github.com/bitcoin/bitcoin/pull/33310)

💬 fanquake commented on pull request "trace: Workaround GCC bug compiling with old systemtap":
(https://github.com/bitcoin/bitcoin/pull/33310#issuecomment-3284792505)
Backported to 30.x in #33356.

💬 fanquake commented on pull request "trace: Workaround GCC bug compiling with old systemtap":
(https://github.com/bitcoin/bitcoin/pull/33310#issuecomment-3284796811)
Backported to 29.x in #33344.

📝 fanquake opened a pull request: "depends: systemtap 5.3"
(https://github.com/bitcoin/bitcoin/pull/33373)
The diff in the copied header is:
```diff
< #if __STDC_VERSION__ >= 199901L
---
> #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
```

From
https://sourceware.org/git/?p=systemtap.git;a=commit;h=b8345d8e07b725a943a97b19aa4866e74baadd98.

📝 Sjors opened a pull request: "mining: add applySolution() to interface"
(https://github.com/bitcoin/bitcoin/pull/33374)
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. It may not have all the information it needs to reconstruct the block. This makes debugging difficult when the block is invalid.

This commit adds `applySolution()` which returns the reconstructed block and can be used by the client for debugging. It's assigned `@11` in the `.cap` file, and will not break existing client
...

💬 Sjors commented on pull request "mining: log failed blocks in submitSolution()":
(https://github.com/bitcoin/bitcoin/pull/33372#issuecomment-3284967478)
I opened #33374 as an alternative or complimentary approach.