💬 ryanofsky commented on pull request "test: have miner_tests use Mining interface":
(https://github.com/bitcoin/bitcoin/pull/31581#discussion_r1900973493)
In commit "test: use Mining interface in miner_tests" (e4e76f27d73646d887ed8b660c67da4b4b785d8e)
Unless I'm misunderstanding something it doesn't seem accurate to say that these don't check if the new block is valid. Would seem more accurate to say they return true even if the block is invalid. Also it would seem be more accurate to say that they update the tip, rather than that they wait for the tip to update.
(https://github.com/bitcoin/bitcoin/pull/31581#discussion_r1900973493)
In commit "test: use Mining interface in miner_tests" (e4e76f27d73646d887ed8b660c67da4b4b785d8e)
Unless I'm misunderstanding something it doesn't seem accurate to say that these don't check if the new block is valid. Would seem more accurate to say they return true even if the block is invalid. Also it would seem be more accurate to say that they update the tip, rather than that they wait for the tip to update.
💬 ryanofsky commented on pull request "test: have miner_tests use Mining interface":
(https://github.com/bitcoin/bitcoin/pull/31581#discussion_r1900981503)
In commit "test: use Mining interface in miner_tests" (e4e76f27d73646d887ed8b660c67da4b4b785d8e)
Seems fine to call waitTipChange if idea is to add more test coverage for it, but wouldn't it be more direct to just check that the new tip matches the block hash if the idea is to check that the block was connected? This way if the block was not connected the test would fail instead of hanging indefinitely.
(https://github.com/bitcoin/bitcoin/pull/31581#discussion_r1900981503)
In commit "test: use Mining interface in miner_tests" (e4e76f27d73646d887ed8b660c67da4b4b785d8e)
Seems fine to call waitTipChange if idea is to add more test coverage for it, but wouldn't it be more direct to just check that the new tip matches the block hash if the idea is to check that the block was connected? This way if the block was not connected the test would fail instead of hanging indefinitely.
💬 i-am-yuvi commented on pull request "fuzz: Abort if system time is called without mock time being set":
(https://github.com/bitcoin/bitcoin/pull/31549#issuecomment-2567974643)
I am unable to crash the fuzz test when `setmocktime()` is removed from one of the targets.
clang version:
```
Homebrew clang version 18.1.7
Target: arm64-apple-darwin24.2.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
```
clang++ version:
```
Homebrew clang version 18.1.7
Target: arm64-apple-darwin24.2.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
```
and I've used this command mentioned in docs for [macos](https://github.com/bitcoin/bit
...
(https://github.com/bitcoin/bitcoin/pull/31549#issuecomment-2567974643)
I am unable to crash the fuzz test when `setmocktime()` is removed from one of the targets.
clang version:
```
Homebrew clang version 18.1.7
Target: arm64-apple-darwin24.2.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
```
clang++ version:
```
Homebrew clang version 18.1.7
Target: arm64-apple-darwin24.2.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
```
and I've used this command mentioned in docs for [macos](https://github.com/bitcoin/bit
...
🤔 pinheadmz reviewed a pull request: "Extend signetchallenge to set target block spacing"
(https://github.com/bitcoin/bitcoin/pull/29365#pullrequestreview-2527798109)
concept ACK
(https://github.com/bitcoin/bitcoin/pull/29365#pullrequestreview-2527798109)
concept ACK
💬 pinheadmz commented on pull request "Extend signetchallenge to set target block spacing":
(https://github.com/bitcoin/bitcoin/pull/29365#discussion_r1901008846)
Why change this? Why not also include nodes 0 & 1?
(https://github.com/bitcoin/bitcoin/pull/29365#discussion_r1901008846)
Why change this? Why not also include nodes 0 & 1?
💬 maflcko commented on pull request "fuzz: Abort if system time is called without mock time being set":
(https://github.com/bitcoin/bitcoin/pull/31549#discussion_r1901022152)
Shouldn't this be `g_used_system_time |= bool(mocktime.count())`? This would allow to remove the `GetMockTime().count() == 0` check as well.
(https://github.com/bitcoin/bitcoin/pull/31549#discussion_r1901022152)
Shouldn't this be `g_used_system_time |= bool(mocktime.count())`? This would allow to remove the `GetMockTime().count() == 0` check as well.
💬 maflcko commented on pull request "refactor: Allow std::byte in Read(LE/BE)":
(https://github.com/bitcoin/bitcoin/pull/31524#discussion_r1901027110)
> Personally, I find the `ByteType auto` construct slightly more confusing than the more verbose template.
Ok, resolving for now.
If there is a preference about the style, my preference would be to have a clang-tidy (plugin) rule for this, instead of using human review resources.
(https://github.com/bitcoin/bitcoin/pull/31524#discussion_r1901027110)
> Personally, I find the `ByteType auto` construct slightly more confusing than the more verbose template.
Ok, resolving for now.
If there is a preference about the style, my preference would be to have a clang-tidy (plugin) rule for this, instead of using human review resources.
💬 pinheadmz commented on pull request "Extend signetchallenge to set target block spacing":
(https://github.com/bitcoin/bitcoin/pull/29365#issuecomment-2568022971)
> This change is backward-compatible, as per the old rules, such a signet challenge would always evaluate to false, rendering it unused.
I don't completely agree with this, since starting an old version of bitcoind with (for example)
`-signetchallenge=6a4c0901ff000000000000004c0151` would create an incompatible node. It would have a different network magic bytes and I think the `OP_RETURN` challenge would cause it to reject all blocks.
(https://github.com/bitcoin/bitcoin/pull/29365#issuecomment-2568022971)
> This change is backward-compatible, as per the old rules, such a signet challenge would always evaluate to false, rendering it unused.
I don't completely agree with this, since starting an old version of bitcoind with (for example)
`-signetchallenge=6a4c0901ff000000000000004c0151` would create an incompatible node. It would have a different network magic bytes and I think the `OP_RETURN` challenge would cause it to reject all blocks.
💬 hebasto commented on pull request "qa: Use `sys.executable` when invoking other Python scripts":
(https://github.com/bitcoin/bitcoin/pull/31541#issuecomment-2568043575)
> Encountered a failure with `tool_wallet` on NetBSD that I want to check out before full ACK.
This issue is fixed in https://github.com/bitcoin/bitcoin/pull/31543. It could be worked around by setting the `LD_LIBRARY_PATH` environment variable.
(https://github.com/bitcoin/bitcoin/pull/31541#issuecomment-2568043575)
> Encountered a failure with `tool_wallet` on NetBSD that I want to check out before full ACK.
This issue is fixed in https://github.com/bitcoin/bitcoin/pull/31543. It could be worked around by setting the `LD_LIBRARY_PATH` environment variable.
💬 i-am-yuvi commented on pull request "Feature: Use different datadirs for different signets":
(https://github.com/bitcoin/bitcoin/pull/29838#issuecomment-2568058991)
Concept ACK
It's a pretty required feature!! I will test it soon!!
(https://github.com/bitcoin/bitcoin/pull/29838#issuecomment-2568058991)
Concept ACK
It's a pretty required feature!! I will test it soon!!
💬 maflcko commented on pull request "test: Call generate RPCs through test framework only":
(https://github.com/bitcoin/bitcoin/pull/31403#issuecomment-2568104009)
The follow-up idea in https://github.com/bitcoin/bitcoin/pull/31403#pullrequestreview-2498806354 is up-for-grabs, if someone is looking for something to work on
(https://github.com/bitcoin/bitcoin/pull/31403#issuecomment-2568104009)
The follow-up idea in https://github.com/bitcoin/bitcoin/pull/31403#pullrequestreview-2498806354 is up-for-grabs, if someone is looking for something to work on
💬 l0rinc commented on pull request "RPC: Add reserve member function to `UniValue` and use it in `getblock` RPC":
(https://github.com/bitcoin/bitcoin/pull/31179#discussion_r1901092142)
> I will leave that as an idea for a follow-up PR.
The problem is that the goal of this PR was to speed up the RPC.
But if we benchmark that instead of just a subset of the task, i.e.:
```patch
diff --git a/src/bench/rpc_blockchain.cpp b/src/bench/rpc_blockchain.cpp
--- a/src/bench/rpc_blockchain.cpp (revision bf5c569898d0297de010102a623bf52009607ed8)
+++ b/src/bench/rpc_blockchain.cpp (date 1735836623994)
@@ -24,7 +24,6 @@
namespace {
struct TestBlockAndIndex {
- const std::
...
(https://github.com/bitcoin/bitcoin/pull/31179#discussion_r1901092142)
> I will leave that as an idea for a follow-up PR.
The problem is that the goal of this PR was to speed up the RPC.
But if we benchmark that instead of just a subset of the task, i.e.:
```patch
diff --git a/src/bench/rpc_blockchain.cpp b/src/bench/rpc_blockchain.cpp
--- a/src/bench/rpc_blockchain.cpp (revision bf5c569898d0297de010102a623bf52009607ed8)
+++ b/src/bench/rpc_blockchain.cpp (date 1735836623994)
@@ -24,7 +24,6 @@
namespace {
struct TestBlockAndIndex {
- const std::
...
💬 i-am-yuvi commented on pull request "test: Call generate RPCs through test framework only":
(https://github.com/bitcoin/bitcoin/pull/31403#issuecomment-2568122327)
> The follow-up idea in https://github.com/bitcoin/bitcoin/pull/31403#pullrequestreview-2498806354 is up-for-grabs, if someone is looking for something to work on
I'll take that!! Thanks for sharing!!
(https://github.com/bitcoin/bitcoin/pull/31403#issuecomment-2568122327)
> The follow-up idea in https://github.com/bitcoin/bitcoin/pull/31403#pullrequestreview-2498806354 is up-for-grabs, if someone is looking for something to work on
I'll take that!! Thanks for sharing!!
✅ maflcko closed a pull request: "fuzz: Faster leak check when generating corpus"
(https://github.com/bitcoin/bitcoin/pull/31481)
(https://github.com/bitcoin/bitcoin/pull/31481)
💬 maflcko commented on issue " (bitcoin core warning: unknown new rules activated versionbit 2) ":
(https://github.com/bitcoin/bitcoin/issues/31536#issuecomment-2568133106)
> i downloaded the newest version of bitcoin core wallet and run it and it finished sync but no balance showing up there either
You may have to rescan, when you load the wallet again, or restore from a backup. Otherwise, the transaction history (and balance) may be missing.
(https://github.com/bitcoin/bitcoin/issues/31536#issuecomment-2568133106)
> i downloaded the newest version of bitcoin core wallet and run it and it finished sync but no balance showing up there either
You may have to rescan, when you load the wallet again, or restore from a backup. Otherwise, the transaction history (and balance) may be missing.
💬 maflcko commented on issue " (bitcoin core warning: unknown new rules activated versionbit 2) ":
(https://github.com/bitcoin/bitcoin/issues/31536#issuecomment-2568133444)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base.
General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat, or one of the Bitcoin subreddits, or any other place that you feel is well suited.
(https://github.com/bitcoin/bitcoin/issues/31536#issuecomment-2568133444)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base.
General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat, or one of the Bitcoin subreddits, or any other place that you feel is well suited.
💬 starius commented on pull request "Extend signetchallenge to set target block spacing":
(https://github.com/bitcoin/bitcoin/pull/29365#issuecomment-2568135949)
> > This change is backward-compatible, as per the old rules, such a signet challenge would always evaluate to false, rendering it unused.
>
> I don't completely agree with this, since starting an old version of bitcoind with (for example) `-signetchallenge=6a4c0901ff000000000000004c0151` would create an incompatible node. It would have a different network magic bytes and I think the `OP_RETURN` challenge would cause it to reject all blocks.
The change is backward-compatible in the sense t
...
(https://github.com/bitcoin/bitcoin/pull/29365#issuecomment-2568135949)
> > This change is backward-compatible, as per the old rules, such a signet challenge would always evaluate to false, rendering it unused.
>
> I don't completely agree with this, since starting an old version of bitcoind with (for example) `-signetchallenge=6a4c0901ff000000000000004c0151` would create an incompatible node. It would have a different network magic bytes and I think the `OP_RETURN` challenge would cause it to reject all blocks.
The change is backward-compatible in the sense t
...
💬 pinheadmz commented on pull request "Extend signetchallenge to set target block spacing":
(https://github.com/bitcoin/bitcoin/pull/29365#issuecomment-2568138710)
> This isn't accurate.
I meant, if you passed the extended challenge to an old version of bitcoin it would compute different magic bytes than if you passed the same challenge to an upgraded node.
(https://github.com/bitcoin/bitcoin/pull/29365#issuecomment-2568138710)
> This isn't accurate.
I meant, if you passed the extended challenge to an old version of bitcoin it would compute different magic bytes than if you passed the same challenge to an upgraded node.
🤔 danielabrozzoni reviewed a pull request: "Fix -norpcwhitelist, -norpcallowip, and similar corner case behavior"
(https://github.com/bitcoin/bitcoin/pull/30529#pullrequestreview-2527941633)
Concept ACK - I still haven't reviewed every commit, but this seems a nice cleanup overall.
(https://github.com/bitcoin/bitcoin/pull/30529#pullrequestreview-2527941633)
Concept ACK - I still haven't reviewed every commit, but this seems a nice cleanup overall.
💬 danielabrozzoni commented on pull request "Fix -norpcwhitelist, -norpcallowip, and similar corner case behavior":
(https://github.com/bitcoin/bitcoin/pull/30529#discussion_r1901095831)
In b8c83c3a90452a35f63daac70d7cdf3ad0f2e280:
The commit message and release notes say that there are corner cases being fixed in `-nosignetseednode` and `-nosignetchallenge`, but I can't seem to reproduce them, as the code disallows the two options:
```
❯ ./build/src/bitcoind -nosignetchallenge
Error: Error parsing command line arguments: Negating of -signetchallenge is meaningless and therefore forbidden
...
(https://github.com/bitcoin/bitcoin/pull/30529#discussion_r1901095831)
In b8c83c3a90452a35f63daac70d7cdf3ad0f2e280:
The commit message and release notes say that there are corner cases being fixed in `-nosignetseednode` and `-nosignetchallenge`, but I can't seem to reproduce them, as the code disallows the two options:
```
❯ ./build/src/bitcoind -nosignetchallenge
Error: Error parsing command line arguments: Negating of -signetchallenge is meaningless and therefore forbidden
...