💬 Sjors commented on pull request "Set notifications m_tip_block in LoadChainTip()":
(https://github.com/bitcoin/bitcoin/pull/31346#issuecomment-2493871800)
I updated the `waitTipChanged()` and `m_tip_block` doc.
@maflcko which if-guard do you mean?
(https://github.com/bitcoin/bitcoin/pull/31346#issuecomment-2493871800)
I updated the `waitTipChanged()` and `m_tip_block` doc.
@maflcko which if-guard do you mean?
💬 ryanofsky commented on pull request "Set notifications m_tip_block in LoadChainTip()":
(https://github.com/bitcoin/bitcoin/pull/31346#issuecomment-2493880145)
> @maflcko which if-guard do you mean?
I think probably this one:
```c++
// Wait for genesis block to be processed
if (WITH_LOCK(chainman.GetMutex(), return chainman.ActiveTip() == nullptr)) {
```
Removing the `if()` might help verify that `m_tip_block` is set reliably
(https://github.com/bitcoin/bitcoin/pull/31346#issuecomment-2493880145)
> @maflcko which if-guard do you mean?
I think probably this one:
```c++
// Wait for genesis block to be processed
if (WITH_LOCK(chainman.GetMutex(), return chainman.ActiveTip() == nullptr)) {
```
Removing the `if()` might help verify that `m_tip_block` is set reliably
💬 maflcko commented on pull request "build: Fix coverage builds":
(https://github.com/bitcoin/bitcoin/pull/31337#issuecomment-2493887018)
Tested via https://github.com/maflcko/DrahtBot/blob/main/coverage_fuzz/src/main.rs (GCC coverage):
* Commit `85224f92d52356483a4e45a1735db02b8612dea6~1`: https://drahtbot.space/host_reports/DrahtBot/reports/coverage_fuzz/monotree/9719d373dc2fb0f2/d964b0cfa3dc534a/fuzz.coverage/index.html
* Commit `01a7298818d7bd66bb8c800d7cd30ae0a4d3b1d1`: https://drahtbot.space/host_reports/DrahtBot/reports/coverage_fuzz/monotree/01a7298818d7bd66/d964b0cfa3dc534a/fuzz.coverage/index.html
* master: *fails*
...
(https://github.com/bitcoin/bitcoin/pull/31337#issuecomment-2493887018)
Tested via https://github.com/maflcko/DrahtBot/blob/main/coverage_fuzz/src/main.rs (GCC coverage):
* Commit `85224f92d52356483a4e45a1735db02b8612dea6~1`: https://drahtbot.space/host_reports/DrahtBot/reports/coverage_fuzz/monotree/9719d373dc2fb0f2/d964b0cfa3dc534a/fuzz.coverage/index.html
* Commit `01a7298818d7bd66bb8c800d7cd30ae0a4d3b1d1`: https://drahtbot.space/host_reports/DrahtBot/reports/coverage_fuzz/monotree/01a7298818d7bd66/d964b0cfa3dc534a/fuzz.coverage/index.html
* master: *fails*
...
💬 maflcko commented on pull request "Set notifications m_tip_block in LoadChainTip()":
(https://github.com/bitcoin/bitcoin/pull/31346#issuecomment-2493892510)
Also, the ZERO workaround could be removed completely, ensuring that any interfaces will only be spun up after that point in init?
(https://github.com/bitcoin/bitcoin/pull/31346#issuecomment-2493892510)
Also, the ZERO workaround could be removed completely, ensuring that any interfaces will only be spun up after that point in init?
👍 ryanofsky approved a pull request: "Drop script_pub_key arg from createNewBlock"
(https://github.com/bitcoin/bitcoin/pull/31318#pullrequestreview-2454619280)
Code review ACK 027ce3e9634b2f47c508899942d05690572de516. Since last review, this was rebased to avoid conflicts, and option is now a plain cscript instead of an optional\<cscript>, and the commits are split up and there are some minor changes in tests (renames, whitespace, dropping redundant assignments. This is pretty easy to review now that the main commit is so small and changes are split up
(https://github.com/bitcoin/bitcoin/pull/31318#pullrequestreview-2454619280)
Code review ACK 027ce3e9634b2f47c508899942d05690572de516. Since last review, this was rebased to avoid conflicts, and option is now a plain cscript instead of an optional\<cscript>, and the commits are split up and there are some minor changes in tests (renames, whitespace, dropping redundant assignments. This is pretty easy to review now that the main commit is so small and changes are split up
💬 maflcko commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r1854018677)
Thanks, cleared the machine
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r1854018677)
Thanks, cleared the machine
💬 Sjors commented on pull request "Set notifications m_tip_block in LoadChainTip()":
(https://github.com/bitcoin/bitcoin/pull/31346#issuecomment-2493919528)
I dropped the if guard.
> ensuring that any interfaces will only be spun up after that point in init
It could, but I'm not sure if it's worth putting such a restriction on the interfaces.
Similarly we have `startupnotify` which happens at the end of init. If we also ensure that the interfaces are ready to listen _before_ this notification, then at least from an application launched with systemd (or similiar) we could expect them to wait for this signal before trying to connect.
If on
...
(https://github.com/bitcoin/bitcoin/pull/31346#issuecomment-2493919528)
I dropped the if guard.
> ensuring that any interfaces will only be spun up after that point in init
It could, but I'm not sure if it's worth putting such a restriction on the interfaces.
Similarly we have `startupnotify` which happens at the end of init. If we also ensure that the interfaces are ready to listen _before_ this notification, then at least from an application launched with systemd (or similiar) we could expect them to wait for this signal before trying to connect.
If on
...
👍 stickies-v approved a pull request: "refactor: Clamp worker threads in ChainstateManager constructor"
(https://github.com/bitcoin/bitcoin/pull/31313#pullrequestreview-2454240562)
ACK 8f85d36d68ab33ba237407a2ed16667eb149d61f
---
I noticed this issue while reviewing #30595, and started working on an [alternative approach](https://github.com/stickies-v/bitcoin/commits/2024-11/add-bounded-integer/) before @TheCharlatan made me aware of this PR. I thought it would be nice to introduce a new `BoundedInt` type, that avoids relying on input validation and instead forces the underlying value to be bound to a (compile time constant) certain range.
However, there were much
...
(https://github.com/bitcoin/bitcoin/pull/31313#pullrequestreview-2454240562)
ACK 8f85d36d68ab33ba237407a2ed16667eb149d61f
---
I noticed this issue while reviewing #30595, and started working on an [alternative approach](https://github.com/stickies-v/bitcoin/commits/2024-11/add-bounded-integer/) before @TheCharlatan made me aware of this PR. I thought it would be nice to introduce a new `BoundedInt` type, that avoids relying on input validation and instead forces the underlying value to be bound to a (compile time constant) certain range.
However, there were much
...
💬 stickies-v commented on pull request "refactor: Clamp worker threads in ChainstateManager constructor":
(https://github.com/bitcoin/bitcoin/pull/31313#discussion_r1853795666)
nit: `CCheckQueue` is used for other things than `ScriptCheck` (in test code), but I don't see a better place to put the log statement, and making it a non-refactor commit by e..g updating the wording to "Verification queue uses ..." is probably not worth it either, so disregarding this nit might be the best way forward.
(https://github.com/bitcoin/bitcoin/pull/31313#discussion_r1853795666)
nit: `CCheckQueue` is used for other things than `ScriptCheck` (in test code), but I don't see a better place to put the log statement, and making it a non-refactor commit by e..g updating the wording to "Verification queue uses ..." is probably not worth it either, so disregarding this nit might be the best way forward.
💬 stickies-v commented on pull request "refactor: Clamp worker threads in ChainstateManager constructor":
(https://github.com/bitcoin/bitcoin/pull/31313#discussion_r1853999686)
Related (but not required for this PR, and currently a no-op), the below patch removing default value duplication would ensure the default `work_threads_num` value doesn't depend on argsmanager being used either:
<details>
<summary>git diff on 8f85d36d68</summary>
```diff
diff --git a/src/init.cpp b/src/init.cpp
index 94a5a08463..61c6f060f1 100644
--- a/src/init.cpp
+++ b/src/init.cpp
@@ -32,6 +32,7 @@
#include <interfaces/ipc.h>
#include <interfaces/mining.h>
#include <interfa
...
(https://github.com/bitcoin/bitcoin/pull/31313#discussion_r1853999686)
Related (but not required for this PR, and currently a no-op), the below patch removing default value duplication would ensure the default `work_threads_num` value doesn't depend on argsmanager being used either:
<details>
<summary>git diff on 8f85d36d68</summary>
```diff
diff --git a/src/init.cpp b/src/init.cpp
index 94a5a08463..61c6f060f1 100644
--- a/src/init.cpp
+++ b/src/init.cpp
@@ -32,6 +32,7 @@
#include <interfaces/ipc.h>
#include <interfaces/mining.h>
#include <interfa
...
💬 ryanofsky commented on pull request "Set notifications m_tip_block in LoadChainTip()":
(https://github.com/bitcoin/bitcoin/pull/31346#issuecomment-2493956840)
> It could, but I'm not sure if it's worth putting such a restriction on the interfaces.
Tend to agree for now. Having waitTipChanged wait for a tip to be connected seems like a natural thing to implement and might avoid the need for clients to poll the node on startup. But I think this check could be dropped in BlockTemplate::waitNext in #31283 (maybe replaced with an assert there) since it should not be possible to get a blocktemplate reference before the tip is connected. After #31283 it m
...
(https://github.com/bitcoin/bitcoin/pull/31346#issuecomment-2493956840)
> It could, but I'm not sure if it's worth putting such a restriction on the interfaces.
Tend to agree for now. Having waitTipChanged wait for a tip to be connected seems like a natural thing to implement and might avoid the need for clients to poll the node on startup. But I think this check could be dropped in BlockTemplate::waitNext in #31283 (maybe replaced with an assert there) since it should not be possible to get a blocktemplate reference before the tip is connected. After #31283 it m
...
💬 maflcko commented on pull request "build: Fix coverage builds":
(https://github.com/bitcoin/bitcoin/pull/31337#issuecomment-2493984478)
> source based code coverage using Clang currently still works fine with master (see: [#31337 (comment)](https://github.com/bitcoin/bitcoin/pull/31337#issuecomment-2490620693)).
Would be nice to do it for this pull as well, to see if there is any difference.
(https://github.com/bitcoin/bitcoin/pull/31337#issuecomment-2493984478)
> source based code coverage using Clang currently still works fine with master (see: [#31337 (comment)](https://github.com/bitcoin/bitcoin/pull/31337#issuecomment-2490620693)).
Would be nice to do it for this pull as well, to see if there is any difference.
🤔 BrandonOdiwuor reviewed a pull request: "Make m_tip_block std::optional"
(https://github.com/bitcoin/bitcoin/pull/31325#pullrequestreview-2454713890)
Concept ACK transitioning `m_tip_block` to `std::optional` which remains unset until a block is connected
(https://github.com/bitcoin/bitcoin/pull/31325#pullrequestreview-2454713890)
Concept ACK transitioning `m_tip_block` to `std::optional` which remains unset until a block is connected
💬 hebasto commented on pull request "build: increase minimum supported Windows to 10.0":
(https://github.com/bitcoin/bitcoin/pull/31172#issuecomment-2493991348)
My Guix build:
```
aarch64
606d0909c4591fc7dac3759e230e7bd3de00555c1c535d437ca8bc19df85fc70 guix-build-ee1128ead846/output/aarch64-linux-gnu/SHA256SUMS.part
4aca1c476b6824d485044c6636ce2ecf45f542a89bc501493f4868cf16c13d1f guix-build-ee1128ead846/output/aarch64-linux-gnu/bitcoin-ee1128ead846-aarch64-linux-gnu-debug.tar.gz
46d17a50226b60af12124b9c2b70cdab1c257a2034463999c0340d8a8b573cdd guix-build-ee1128ead846/output/aarch64-linux-gnu/bitcoin-ee1128ead846-aarch64-linux-gnu.tar.gz
d82c381c
...
(https://github.com/bitcoin/bitcoin/pull/31172#issuecomment-2493991348)
My Guix build:
```
aarch64
606d0909c4591fc7dac3759e230e7bd3de00555c1c535d437ca8bc19df85fc70 guix-build-ee1128ead846/output/aarch64-linux-gnu/SHA256SUMS.part
4aca1c476b6824d485044c6636ce2ecf45f542a89bc501493f4868cf16c13d1f guix-build-ee1128ead846/output/aarch64-linux-gnu/bitcoin-ee1128ead846-aarch64-linux-gnu-debug.tar.gz
46d17a50226b60af12124b9c2b70cdab1c257a2034463999c0340d8a8b573cdd guix-build-ee1128ead846/output/aarch64-linux-gnu/bitcoin-ee1128ead846-aarch64-linux-gnu.tar.gz
d82c381c
...
💬 hebasto commented on pull request "build: Fix coverage builds":
(https://github.com/bitcoin/bitcoin/pull/31337#issuecomment-2493995709)
> > source based code coverage using Clang currently still works fine with master (see: [#31337 (comment)](https://github.com/bitcoin/bitcoin/pull/31337#issuecomment-2490620693)).
>
> Would be nice to do it for this pull as well, to see if there is any difference.
cc @dergoegge
(https://github.com/bitcoin/bitcoin/pull/31337#issuecomment-2493995709)
> > source based code coverage using Clang currently still works fine with master (see: [#31337 (comment)](https://github.com/bitcoin/bitcoin/pull/31337#issuecomment-2490620693)).
>
> Would be nice to do it for this pull as well, to see if there is any difference.
cc @dergoegge
💬 ryanofsky commented on pull request "util: Improve documentation and negation of args":
(https://github.com/bitcoin/bitcoin/pull/31212#discussion_r1854105033)
Apologies l0rinc. I think we are probably just misunderstanding each other. All the checks you are suggesting are possible with the approach I'm suggesting, and it should only make them easier to implement and understand. And I might not understand what approach you prefer since your first comment https://github.com/bitcoin/bitcoin/pull/31212#discussion_r1850778259 seems to want new tests to be in the same commit as the bugfix, but the last one https://github.com/bitcoin/bitcoin/pull/31212#discu
...
(https://github.com/bitcoin/bitcoin/pull/31212#discussion_r1854105033)
Apologies l0rinc. I think we are probably just misunderstanding each other. All the checks you are suggesting are possible with the approach I'm suggesting, and it should only make them easier to implement and understand. And I might not understand what approach you prefer since your first comment https://github.com/bitcoin/bitcoin/pull/31212#discussion_r1850778259 seems to want new tests to be in the same commit as the bugfix, but the last one https://github.com/bitcoin/bitcoin/pull/31212#discu
...
💬 davidgumberg commented on pull request "build: increase minimum supported Windows to 10.0":
(https://github.com/bitcoin/bitcoin/pull/31172#issuecomment-2494069961)
ACK https://github.com/bitcoin/bitcoin/commit/ee1128ead846698db5e5633f193883837f2fbc64
(https://github.com/bitcoin/bitcoin/pull/31172#issuecomment-2494069961)
ACK https://github.com/bitcoin/bitcoin/commit/ee1128ead846698db5e5633f193883837f2fbc64
💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r1854157411)
Thank you!
(https://github.com/bitcoin/bitcoin/pull/30997#discussion_r1854157411)
Thank you!
💬 Sjors commented on pull request "Set notifications m_tip_block in LoadChainTip()":
(https://github.com/bitcoin/bitcoin/pull/31346#issuecomment-2494100649)
Several reindex related tests are broken, investigating...
> After https://github.com/bitcoin/bitcoin/pull/31283 it might make sense to drop the `waitTipChanged` method entirely too.
I think it's generically useful though. There are various types of applications that need to know when a new block is added to the chain.
(https://github.com/bitcoin/bitcoin/pull/31346#issuecomment-2494100649)
Several reindex related tests are broken, investigating...
> After https://github.com/bitcoin/bitcoin/pull/31283 it might make sense to drop the `waitTipChanged` method entirely too.
I think it's generically useful though. There are various types of applications that need to know when a new block is added to the chain.
👍 instagibbs approved a pull request: "rpc: Remove submitblock pre-checks"
(https://github.com/bitcoin/bitcoin/pull/31175#pullrequestreview-2455019300)
ACK 73db95c65c1d372822166045ca8b9f173d5fd883
Not an expert here but motivation makes a lot of sense, and good to remove such indirect code from past covert fixes
(https://github.com/bitcoin/bitcoin/pull/31175#pullrequestreview-2455019300)
ACK 73db95c65c1d372822166045ca8b9f173d5fd883
Not an expert here but motivation makes a lot of sense, and good to remove such indirect code from past covert fixes