💬 pinheadmz commented on issue "RPC: getblock(header) returns the same target for every block":
(https://github.com/bitcoin/bitcoin/issues/33440#issuecomment-3314372951)
This is expected, see https://github.com/bitcoin/bitcoin/pull/31583 and https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-29.0.md#updated-rpcs

> getblock and getblockheader now return the current target in the target field (#31583)

🤔 w0xlt reviewed a pull request: "kernel: Introduce initial C header API"
(https://github.com/bitcoin/bitcoin/pull/30595#pullrequestreview-3247953537)
Approach ACK

I’ve been using this API in a project for a few days, and it’s been working really well so far.

💬 w0xlt commented on pull request "kernel: Introduce initial C header API":
(https://github.com/bitcoin/bitcoin/pull/30595#discussion_r2365027768)
Wouldn’t it make sense to expose the ` ScriptError` ?
If validation fails, the user might need to know the reason.

💬 gmart7t2 commented on issue "RPC: getblock(header) returns the same target for every block":
(https://github.com/bitcoin/bitcoin/issues/33440#issuecomment-3314536588)
That looks like a release note error to me. Why would we want to know the current target when looking up information about an old block?

The help text for the RPC calls says that it returns the difficulty target and difficulty of blockheader `<hash>`:


It makes no sense to return the target for a different block's difficulty. It means that the block header information returned for old blocks changes over
...

💬 gmart7t2 commented on issue "RPC: getblock(header) returns the same target for every block":
(https://github.com/bitcoin/bitcoin/issues/33440#issuecomment-3314545849)
This tiny change changes both RPCs to return the target for the block of interest rather than the current target:

```
diff --git a/src/rpc/blockchain.cpp b/src/rpc/blockchain.cpp
index 8cbca51ccb..edda17d369 100644
--- a/src/rpc/blockchain.cpp
+++ b/src/rpc/blockchain.cpp
@@ -164,7 +164,7 @@ UniValue blockheaderToJSON(const CBlockIndex& tip, const CBlockIndex& blockindex
result.pushKV("mediantime", blockindex.GetMedianTimePast());
result.pushKV("nonce", blockindex.nNonce);
result
...

⚠️ Johnpapandreou21 opened an issue: "Fr to"
(https://github.com/bitcoin/bitcoin/issues/33441)
### Please describe the feature you'd like to see added.

Fr ton

### Is your feature related to a problem, if so please describe it.

_No response_

### Describe the solution you'd like

_No response_

### Describe any alternatives you've considered

_No response_

### Please leave any additional context

_No response_

💬 vasild commented on pull request "system: silence unused variable warning and make GetTotalRAM() work on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/33435#issuecomment-3314600809)
`2b6497b035...8fcf71ca00`: pick suggestions

> cherry-pick [l0rinc/bitcoin@f011c2c](https://github.com/l0rinc/bitcoin/pull/39/commits/f011c2cdf170dbd53c7ec2e46379238579232d67)

done with some minor changes, see `git range-diff f011c2cd~..f011c2cd 8fcf71ca00~..8fcf71ca00`

💬 vasild commented on pull request "system: silence unused variable warning and make GetTotalRAM() work on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/33435#discussion_r2365334320)
Done.

📝 l0rinc opened a pull request: "validation: make the "rolling forward" loop interruptible"
(https://github.com/bitcoin/bitcoin/pull/33442)
### Summary

Restarting an unsuccessful reindex can result in replay of previously indexed blocks. This process can take many hours and is currently not interruptible.

### Reproducer:
* start a normal ibd, stop after some progress
* do a reindex, stop before it finishes
* restart the node normally without specifying the reindex parameter It should start rolling the blocks forward.

After this change you should be able to interrupt the process:
```
2025-09-20T05:35:42Z Rolling forward
...

✅ achow101 closed an issue: "Fr to"
(https://github.com/bitcoin/bitcoin/issues/33441)

📝 l0rinc opened a pull request: "log: don't rate limit "rolling forward" messages"
(https://github.com/bitcoin/bitcoin/pull/33443)
On an incomplete reindex the blocks will need to be replayed. This results in excessive `Rolling forward` which quickly triggers the recently introduced log rate limiter. Since the corresponding `UpdateTipLog` is also not rate limited, we can either remove the rate limit here as well or change logging to display fewer rolling forward messages. This PR does the first.

Reproducer:
* start a normal ibd, stop after some progress
* do a reindex, stop before it finishes
* restart the node normal
...

🤔 mzumsande reviewed a pull request: "validation: make the "rolling forward" loop interruptible"
(https://github.com/bitcoin/bitcoin/pull/33442#pullrequestreview-3248539713)
I did this in #30155 a while back, but in a way such that any partial progress would be saved, and we continue with the next startup.

In any case, now that we flush every hour it's probably a less pressing issue.

👍 l0rinc approved a pull request: "system: improve handling around GetTotalRAM()"
(https://github.com/bitcoin/bitcoin/pull/33435#pullrequestreview-3248537350)
ACK 8fcf71ca005449e639f189dec7ec0163a07e6d37

Reproduced the unused clamp on FreeBSD and that the fix returns the correct memory on FreeBSD and NetBSD and OpenBSD as well (`__illumos__` was tested by @hebasto).
I have also tested that on systems that don't support the memory query the test is gracefully skipped and reported as skipped.

Thanks for the quick fix.

💬 l0rinc commented on pull request "system: improve handling around GetTotalRAM()":
(https://github.com/bitcoin/bitcoin/pull/33435#discussion_r2365342452)
I think this should likely be:
```suggestion
"skipping total_ram_test"
```

✅ l0rinc closed a pull request: "validation: make the "rolling forward" loop interruptible"
(https://github.com/bitcoin/bitcoin/pull/33442)

💬 l0rinc commented on pull request "validation: make the "rolling forward" loop interruptible":
(https://github.com/bitcoin/bitcoin/pull/33442#issuecomment-3314621836)
Closing in favor of https://github.com/bitcoin/bitcoin/pull/30155

💬 l0rinc commented on pull request "validation: Make ReplayBlocks interruptible":
(https://github.com/bitcoin/bitcoin/pull/30155#issuecomment-3314625043)
I have tested this with a recent interrupted reindex, it correctly interrupts and flushes and on next start continues from where we left off:
```
2025-09-20T06:11:25Z Rolling forward 00000000127100b0bcdde9e9f363ae231c73e885e2d527821ef9ce0457930494 (51141)
2025-09-20T06:11:25Z Rolling forward 0000000013484b73eff09514abc3f916b319eb9f43c55f051be9e760ad2210d0 (51142)
^C2025-09-20T06:11:25Z Flushing intermediate state of replay
2025-09-20T06:11:25Z [error] Unable to replay blocks. You will need
...

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