💬 hebasto commented on pull request "system: silence unused variable warning and make GetTotalRAM() work on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/33435#issuecomment-3313992139)
> If we do want to make sure unsupported systems pass gracefully, can we at least add a warning test log for those cases?

I’d say that the `total_ram` test should be:
1) Skipped on unsupported platforms with an explanatory message;
2) Placed into its own test suite so that `ctest` can clearly distinguish and report the skipped test in the statistics.

💬 l0rinc commented on pull request "log: always print initial script verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2364654157)
Done

💬 l0rinc commented on pull request "log: always print initial script verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2364654341)
I don't think it makes much difference, but looks like you do, so I have changed it to `const char*`, let me know what you think.

💬 l0rinc commented on pull request "system: silence unused variable warning and make GetTotalRAM() work on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/33435#discussion_r2364674969)
`NetBSD` also finished successfully: https://github.com/l0rinc/bitcoin/actions/runs/17870748757/job/50823702246?pr=39

💬 l0rinc commented on pull request "system: silence unused variable warning and make GetTotalRAM() work on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/33435#issuecomment-3314050255)
Good idea @hebasto, @vasild can you please cherry-pick [l0rinc/bitcoin@`f011c2c` (#39)](https://github.com/l0rinc/bitcoin/pull/39/commits/f011c2cdf170dbd53c7ec2e46379238579232d67) on top of the PR?
Please add @hebasto as a coauthor.

💬 l0rinc commented on pull request "index: handle case where pindex_prev equals chain tip in NextSyncBlock()":
(https://github.com/bitcoin/bitcoin/pull/32875#discussion_r2364845277)
Not sure what you mean, I prefer having a test that I can run with and without the fix to debug both cases to understand the change better. Otherwise this just looks like a random change that we can just revert and the CI wouldn't even catch it.

💬 l0rinc commented on pull request "test: don't throw from the destructor of DebugLogHelper":
(https://github.com/bitcoin/bitcoin/pull/33388#issuecomment-3314211120)
Code review reACK 2427939935f3e6669be6bf553be89639e0afabaa

⚠️ gmart7t2 opened an issue: "RPC: getblock(header) returns the same target for every block"
(https://github.com/bitcoin/bitcoin/issues/33440)
### Is there an existing issue for this?

- [x] I have searched the existing issues

### Current behaviour

Run `getblock` or `getblockheader` for block 1 and you get the same "target" reported as for block 900000

### Expected behaviour

I would expect the target to be different for different blocks

### Steps to reproduce

Run `getblock` or `getblockheader` for block 1 and you get the same "target" reported as for block 900000

### Relevant log output

_No response_

### How did you obtain Bit
...

💬 pinheadmz commented on issue "RPC: getblock(header) returns the same target for every block":
(https://github.com/bitcoin/bitcoin/issues/33440#issuecomment-3314297074)
Can you paste the exact commands and responses you're getting?

Here's how I do it:

```
$ bitcoin-cli getblockheader `bitcoin-cli getblockhash 1`
{
"hash": "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048",
"confirmations": 915498,
"height": 1,
"version": 1,
"versionHex": "00000001",
"merkleroot": "0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098",
"time": 1231469665,
"mediantime": 1231469665,
"nonce": 2573394689,
"bits": "1d00ffff",
"targe
...

💬 pinheadmz commented on issue "RPC: getblock(header) returns the same target for every block":
(https://github.com/bitcoin/bitcoin/issues/33440#issuecomment-3314304664)
Hm yeah...

```
pi@zippi:~ $ bitcoin-cli getblockheader `bitcoin-cli getblockhash 1` | jq .target
"00000000000000000001fa380000000000000000000000000000000000000000"
pi@zippi:~ $ bitcoin-cli getblockheader `bitcoin-cli getblockhash 100` | jq .target
"00000000000000000001fa380000000000000000000000000000000000000000"
pi@zippi:~ $ bitcoin-cli getblockheader `bitcoin-cli getblockhash 200000` | jq .target
"00000000000000000001fa380000000000000000000000000000000000000000"
pi@zippi:~ $ bitcoin-cli getbl
...

💬 pinheadmz commented on issue "RPC: getblock(header) returns the same target for every block":
(https://github.com/bitcoin/bitcoin/issues/33440#issuecomment-3314307143)
I believe it's always showing the current difficulty target for the next block

💬 pinheadmz commented on issue "RPC: getblock(header) returns the same target for every block":
(https://github.com/bitcoin/bitcoin/issues/33440#issuecomment-3314308293)
https://github.com/bitcoin/bitcoin/blob/11d80d4187afaa101de989330fa1982cd019cfa8/src/rpc/blockchain.cpp#L149-L177

💬 gmart7t2 commented on issue "RPC: getblock(header) returns the same target for every block":
(https://github.com/bitcoin/bitcoin/issues/33440#issuecomment-3314350959)
Yes. It's the same as reported by `getblockchaininfo`:

```
$ bitcoin-cli getblockchaininfo | jq .target
"00000000000000000001fa380000000000000000000000000000000000000000"
```

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