💬 hebasto commented on pull request "system: silence unused variable warning and make GetTotalRAM() work on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/33435#issuecomment-3313959247)
> > Otherwise, this test will fail on any unmentioned system
>
> That's exactly why it was added so that we can detect and cover those. Is it too strict?

We usually avoid breaking people’s tests just to collect coverage data :)

💬 hodlinator commented on pull request "log: always print initial script verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2364630671)
Curious what other reviewers think, but not a blocker.

💬 hebasto commented on pull request "system: silence unused variable warning and make GetTotalRAM() work on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/33435#discussion_r2364631092)
> Does it display the correct value if we print `GetTotalRAM()`?

Yes, it does.

💬 l0rinc commented on pull request "system: silence unused variable warning and make GetTotalRAM() work on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/33435#issuecomment-3313964858)
I assumed we want to be notified about unsupported systems, is that not the case?

💬 l0rinc commented on pull request "log: always print initial script verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#discussion_r2364638838)
I find it important to modify this area of the code in tiny steps, it's why I separated the two concerns in the first place.

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