💬 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_r2365380262)
Thanks again for the review, I have pushed a change to fix the CI and took a few suggestion from your branch (chunking, code simplifications), but kept the original file iteration with progress indicator for now.
The parallelization complicates the situation considerably, I will see if I can find a simpler way or if single-threaded execution is also acceptable.

💬 vasild commented on pull request "system: improve handling around GetTotalRAM()":
(https://github.com/bitcoin/bitcoin/pull/33435#discussion_r2365387629)
By the way:
```
warning: implicit conversion changes signedness: 'long' to 'unsigned long long' [-Wsign-conversion]
... return clamp(1ULL * p * s);
... ~ ^
```
changing it to
```cpp
clamp(static_cast<uint64_t>(p) * static_cast<uint64_t>(s))
```
silences that. `-Wsign-conversion` also enabled by `-Wconversion` is not used by Bitcoin Core, so we don't see it when compiling. In this case the code is ok because values are explicitly checked that they are greater than 0 be
...

💬 TheCharlatan commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2365546655)
I think it would be a nice addition. Others have asked for it too before. I'm not sure about the best approach to expose them though. Should we just copy them, or make the header installable and reuse it for both our internal code and the external API?

✅ fanquake closed a pull request: "[30.0] Final changes + rc2"
(https://github.com/bitcoin/bitcoin/pull/33424)

📝 fanquake reopened a pull request: "[30.0] Final changes + rc2"
(https://github.com/bitcoin/bitcoin/pull/33424)
Backports:
* #28592
* #33420

Finalise `v30.0rc2`

💬 fanquake commented on pull request "build: Remove lingering Windows registry & shortcuts (#32132 follow-up)":
(https://github.com/bitcoin/bitcoin/pull/33422#issuecomment-3314831522)
Backported to 30.x in #33424.

💬 pinheadmz commented on issue "RPC: getblock(header) returns the same target for every block":
(https://github.com/bitcoin/bitcoin/issues/33440#issuecomment-3314882141)
> Why would we want to know the current target when looking up information about an old block?

@Sjors

💬 sdaftuar commented on pull request "Cluster mempool implementation":
(https://github.com/bitcoin/bitcoin/pull/28676#discussion_r2365588805)
Good catch -- I'm working on a solution to this, possibly involving a more extensive rewrite of the TRUC checks (to not need parents/ancestors explicitly calculated) and the RBF checks (to not require ancestors to be calculated before we verify that the cluster size limits are respected).

💬 john-moffett commented on pull request "rpc: Always return per-wtxid entries in submitpackage tx-results":
(https://github.com/bitcoin/bitcoin/pull/33427#discussion_r2365625178)
This is somewhat academic today as the RPC already [errors](https://github.com/bitcoin/bitcoin/blob/df101c97c260793627208d8c334afc9551759e2b/src/rpc/mempool.cpp#L1054) on anything but all-or-none results from `ProcessNewPackage`:

`CHECK_NONFATAL(m_tx_results.size() == txns.size() || m_tx_results.empty())`

So if partial maps from `ProcessNewPackage` were ever done in practice, a call to `submitpackage` would run into that first check. If that guard were relaxed and tested to accommodate the
...

📝 enirox001 opened a pull request: "rpc: Fix dumptxoutset rollback with competing forks"
(https://github.com/bitcoin/bitcoin/pull/33444)
Fixes dumptxoutset rollback functionality when competing forks exist.

**Problem:**
dumptxoutset rollback fails when competing forks are present at the target height, even though it should work on the active chain regardless of forks.

Attempts to fix #32817.

**Solution:**
- Fix rollback logic to handle competing forks correctly
- Add test coverage for the fix

**Changes:**
- Add functional test demonstrating the issue and verifying the fix
- Update dumptxoutset rollback implementa
...

💬 fanquake commented on pull request "fuzz: reduce iterations in slow targets":
(https://github.com/bitcoin/bitcoin/pull/33429#issuecomment-3314984363)
@furszy Could you PR that branch separately?

🚀 fanquake merged a pull request: "fuzz: reduce iterations in slow targets"
(https://github.com/bitcoin/bitcoin/pull/33429)

✅ fanquake closed an issue: "fuzz: Speed up mini_miner fuzz target?"
(https://github.com/bitcoin/bitcoin/issues/32870)

💬 fanquake commented on issue "fuzz: Speed up mini_miner fuzz target?":
(https://github.com/bitcoin/bitcoin/issues/32870#issuecomment-3314986378)
Think we can close this based on #33429.

✅ Sjors closed a pull request: "mining: add applySolution() to interface"
(https://github.com/bitcoin/bitcoin/pull/33374)

💬 Sjors commented on pull request "mining: add applySolution() to interface":
(https://github.com/bitcoin/bitcoin/pull/33374#issuecomment-3314987630)
> 1. Main question is why is this new applySolution method needed at all if `submitSolution()` modifies the block and there is already a `getBlock()` method?

This is a great point. Let's just embrace the fact that `submitSolution()` modifies the block.

I'll extract some of the documentation improvements, and add some based on your comments, and PR those later.

💬 Sjors commented on pull request "mining: add applySolution() to interface":
(https://github.com/bitcoin/bitcoin/pull/33374#discussion_r2365640546)
This test only calls `submitSolution()` once, unless I'm missing something?

💬 Sjors commented on pull request "rpc: add target to getmininginfo field and show next block info":
(https://github.com/bitcoin/bitcoin/pull/31583#discussion_r2365643082)
In 2a7bfebd5e788e1d9e7e07a9f1b8e3625a0301cd _Add target to getblock(header) in RPC and REST_: as pointed out in #33440 this is a bug. Unlike `getmininginfo` in baa504fdfaff4a9f61bc939035df5d5f2978cfd7 and `getblockchaininfo` in f153f57acc9f9a6f84af161d5bed9aa9965abaa3, we should not use the `tip` here but `blockindex` (like for nBits).

💬 TheCharlatan commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#issuecomment-3315058883)
Updated 0fc068b735d267c7ef4a3b23e32dab1771df2509 -> 2ac9d60c54a777978101c369f5895a933208a44c ([kernelApi_65](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_65) -> [kernelApi_66](https://github.com/TheCharlatan/bitcoin/tree/kernelApi_66), [compare](https://github.com/TheCharlatan/bitcoin/compare/kernelApi_65..kernelApi_66))

* Changed `btck_BlockHash` into an opaque struct.
* Improved coverage from the tests a bit.

💬 Sjors commented on issue "RPC: getblock(header) returns the same target for every block":
(https://github.com/bitcoin/bitcoin/issues/33440#issuecomment-3315061205)
This is indeed a bug. The other commits in that PR use the tip, but that's incorrect for these methods. See https://github.com/bitcoin/bitcoin/pull/31583/commits/2a7bfebd5e788e1d9e7e07a9f1b8e3625a0301cd#r2365643082

I'll PR a fix shortly, still working on adding test coverage.