💬 vasild commented on pull request "util: explicitly close all AutoFiles that have been written":
(https://github.com/bitcoin/bitcoin/pull/29307#issuecomment-3076765123)
I prefer to always check whether a syscall failed even if it _seems_ that it should always succeed. In this particular case, the _"seems"_ is not very strong because `close` is doing [more things](https://github.com/bitcoin/bitcoin/pull/29307#discussion_r2161473468) than `flush` or `truncate` and those things could fail. So I think the current code is solid. I do not see a value in removing a check whether `close` failed.
(https://github.com/bitcoin/bitcoin/pull/29307#issuecomment-3076765123)
I prefer to always check whether a syscall failed even if it _seems_ that it should always succeed. In this particular case, the _"seems"_ is not very strong because `close` is doing [more things](https://github.com/bitcoin/bitcoin/pull/29307#discussion_r2161473468) than `flush` or `truncate` and those things could fail. So I think the current code is solid. I do not see a value in removing a check whether `close` failed.
📝 maflcko opened a pull request: "init: [gui] Avoid UB/crash in InitAndLoadChainstate"
(https://github.com/bitcoin/bitcoin/pull/32987)
`InitAndLoadChainstate` is problematic, when called twice in the GUI. This can happen when it returns a failure and the user selects an interactive reindex.
There are several bugs that have been introduced since the last time this was working correctly:
* The first one is a crash (assertion failure), which happens due to a cached tip block in the notifiications from the previous run. See https://github.com/bitcoin/bitcoin/pull/31346#discussion_r2207914726
* The second one is UB (use-after
...
(https://github.com/bitcoin/bitcoin/pull/32987)
`InitAndLoadChainstate` is problematic, when called twice in the GUI. This can happen when it returns a failure and the user selects an interactive reindex.
There are several bugs that have been introduced since the last time this was working correctly:
* The first one is a crash (assertion failure), which happens due to a cached tip block in the notifiications from the previous run. See https://github.com/bitcoin/bitcoin/pull/31346#discussion_r2207914726
* The second one is UB (use-after
...
✅ maflcko closed a pull request: "test: Check that the GUI interactive reindex works"
(https://github.com/bitcoin/bitcoin/pull/32979)
(https://github.com/bitcoin/bitcoin/pull/32979)
💬 maflcko commented on pull request "test: Check that the GUI interactive reindex works":
(https://github.com/bitcoin/bitcoin/pull/32979#issuecomment-3076792505)
fix (and this test) in https://github.com/bitcoin/bitcoin/pull/32987
(https://github.com/bitcoin/bitcoin/pull/32979#issuecomment-3076792505)
fix (and this test) in https://github.com/bitcoin/bitcoin/pull/32987
👍 rkrux approved a pull request: "wallet: Set migrated wallet name only on success"
(https://github.com/bitcoin/bitcoin/pull/32984#pullrequestreview-3023217816)
lgtm ACK 8a4cfddf23a4575a1042dfa97d3478727775e8dd
Makes sense to add this.
I recall thinking once about adding something like this when I was working on #32758, but I forgot later.
(https://github.com/bitcoin/bitcoin/pull/32984#pullrequestreview-3023217816)
lgtm ACK 8a4cfddf23a4575a1042dfa97d3478727775e8dd
Makes sense to add this.
I recall thinking once about adding something like this when I was working on #32758, but I forgot later.
💬 romanz commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2209316365)
nit: `items` size will be the total number of this block's inputs (not its transactions' count), right?
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2209316365)
nit: `items` size will be the total number of this block's inputs (not its transactions' count), right?
💬 romanz commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2209321522)
Looks similar to the code above - maybe refactor into a helper function?
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2209321522)
Looks similar to the code above - maybe refactor into a helper function?
💬 romanz commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2209333265)
Consider using `FlatFilePos` here (which contains 2 `int`s) instead of `CDiskTxPos` (which contains also the block's offset, taking an additional `int`).
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2209333265)
Consider using `FlatFilePos` here (which contains 2 `int`s) instead of `CDiskTxPos` (which contains also the block's offset, taking an additional `int`).
💬 romanz commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2209336131)
Do we need the header's data?
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2209336131)
Do we need the header's data?
💬 maflcko commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2209414266)
nit: Using uint32_t and something like this should fix the linker error:
```
diff --git a/src/rpc/util.cpp b/src/rpc/util.cpp
index 5da02b4df4..0604dec2dc 100644
--- a/src/rpc/util.cpp
+++ b/src/rpc/util.cpp
@@ -731,6 +731,7 @@ TMPL_INST(CheckRequiredOrDefault, const UniValue&, *CHECK_NONFATAL(maybe_arg););
TMPL_INST(CheckRequiredOrDefault, bool, CHECK_NONFATAL(maybe_arg)->get_bool(););
TMPL_INST(CheckRequiredOrDefault, int, CHECK_NONFATAL(maybe_arg)->getInt<int>(););
TMPL_INST(CheckRequired
...
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2209414266)
nit: Using uint32_t and something like this should fix the linker error:
```
diff --git a/src/rpc/util.cpp b/src/rpc/util.cpp
index 5da02b4df4..0604dec2dc 100644
--- a/src/rpc/util.cpp
+++ b/src/rpc/util.cpp
@@ -731,6 +731,7 @@ TMPL_INST(CheckRequiredOrDefault, const UniValue&, *CHECK_NONFATAL(maybe_arg););
TMPL_INST(CheckRequiredOrDefault, bool, CHECK_NONFATAL(maybe_arg)->get_bool(););
TMPL_INST(CheckRequiredOrDefault, int, CHECK_NONFATAL(maybe_arg)->getInt<int>(););
TMPL_INST(CheckRequired
...
📝 maflcko opened a pull request: "test: Trigger UB in wallet crosschain migration"
(https://github.com/bitcoin/bitcoin/pull/32988)
(https://github.com/bitcoin/bitcoin/pull/32988)
💬 maflcko commented on pull request "wallet: Set migrated wallet name only on success":
(https://github.com/bitcoin/bitcoin/pull/32984#issuecomment-3077217292)
> I was unable to write a working functional test for this behavior.
It should be pretty trivial, see https://github.com/bitcoin/bitcoin/pull/32988
(https://github.com/bitcoin/bitcoin/pull/32984#issuecomment-3077217292)
> I was unable to write a working functional test for this behavior.
It should be pretty trivial, see https://github.com/bitcoin/bitcoin/pull/32988
💬 stickies-v commented on pull request "rpc, test: Fix JSON parsing errors in unloadwallet and getdescriptoractivity RPCs":
(https://github.com/bitcoin/bitcoin/pull/32845#discussion_r2209481857)
Oh no I'm not talking about the helper function's parameter name, that's fine imo, I'm talking about the error message that's thrown and eventually returned to the user, referencing an RPC parameter that potentially doesn't exist. Again, no biggie, just a symptom that concerns aren't entirely separated.
(https://github.com/bitcoin/bitcoin/pull/32845#discussion_r2209481857)
Oh no I'm not talking about the helper function's parameter name, that's fine imo, I'm talking about the error message that's thrown and eventually returned to the user, referencing an RPC parameter that potentially doesn't exist. Again, no biggie, just a symptom that concerns aren't entirely separated.
💬 maflcko commented on pull request "wallet: Remove `upgradewallet` RPC":
(https://github.com/bitcoin/bitcoin/pull/32944#issuecomment-3077308944)
migrated wallets will take over the legacy bdb version, which I am not sure is meaningful or useful. The `upgradewallet` RPC can be used to bump it. I think it would be good to explain and document the expectations around this, and the interactions with this pull, going forward.
(https://github.com/bitcoin/bitcoin/pull/32944#issuecomment-3077308944)
migrated wallets will take over the legacy bdb version, which I am not sure is meaningful or useful. The `upgradewallet` RPC can be used to bump it. I think it would be good to explain and document the expectations around this, and the interactions with this pull, going forward.
💬 maflcko commented on issue "ARM Windows build and release":
(https://github.com/bitcoin/bitcoin/issues/31388#issuecomment-3077357630)
You are probably looking for https://bitcoincore.org/en/download, but I don't think this will ever ship msvc compiled binaries, because they are non-deterministic and proprietary (c) . If you really want them, you'll have to compile them yourself. In the meantime, emulation (running the x86 on arm) should work fine.
(https://github.com/bitcoin/bitcoin/issues/31388#issuecomment-3077357630)
You are probably looking for https://bitcoincore.org/en/download, but I don't think this will ever ship msvc compiled binaries, because they are non-deterministic and proprietary (c) . If you really want them, you'll have to compile them yourself. In the meantime, emulation (running the x86 on arm) should work fine.
💬 maflcko commented on pull request "[IBD] log start of script validation past `assumevalid` block":
(https://github.com/bitcoin/bitcoin/pull/32975#discussion_r2209567919)
Not sure what the point is of logging this, when it doesn't detect the case when the checks are enabled initially (due to the minchainwork being less than two weeks worth of headers on top of the av block) ? See also https://github.com/bitcoin/bitcoin/pull/31615
(https://github.com/bitcoin/bitcoin/pull/32975#discussion_r2209567919)
Not sure what the point is of logging this, when it doesn't detect the case when the checks are enabled initially (due to the minchainwork being less than two weeks worth of headers on top of the av block) ? See also https://github.com/bitcoin/bitcoin/pull/31615
✅ maflcko closed a pull request: "test: Trigger UB in wallet crosschain migration"
(https://github.com/bitcoin/bitcoin/pull/32988)
(https://github.com/bitcoin/bitcoin/pull/32988)
💬 josibake commented on pull request "Silent Payments: Receiving":
(https://github.com/bitcoin/bitcoin/pull/32966#discussion_r2209598289)
Worth mentioning, the only reason we wouldn't be able to do this is if this function (and `TopUp`) are called generically on SPKMans, e.g., in a loop. I don't think this is the case, but wanted to mention it.
(https://github.com/bitcoin/bitcoin/pull/32966#discussion_r2209598289)
Worth mentioning, the only reason we wouldn't be able to do this is if this function (and `TopUp`) are called generically on SPKMans, e.g., in a loop. I don't think this is the case, but wanted to mention it.
💬 saikiran57 commented on pull request "Added rescan option for import descriptors":
(https://github.com/bitcoin/bitcoin/pull/31668#discussion_r2209623040)
Hi @achow101 kindly give some update on this.
(https://github.com/bitcoin/bitcoin/pull/31668#discussion_r2209623040)
Hi @achow101 kindly give some update on this.
📝 willcl-ark opened a pull request: "Migrate CI to hosted Cirrus Runners"
(https://github.com/bitcoin/bitcoin/pull/32989)
This changeset migrates all current self-hosted CI jobs over to hosted [Cirrus Runners](https://cirrus-runners.app/).
These runners cost a flat rate of $150/month, and we qualify for an open source discount of 50%. Therefore they are $75/month/runner.
One "runner" should more accurately be thought of in terms of the number of vCPU you are purchasing: https://cirrus-runners.app/pricing/ or in terms of "concurrency", where 1 runners gets you 1.0 concurrency.
e.g. a Linux x86 Runner gets you
...
(https://github.com/bitcoin/bitcoin/pull/32989)
This changeset migrates all current self-hosted CI jobs over to hosted [Cirrus Runners](https://cirrus-runners.app/).
These runners cost a flat rate of $150/month, and we qualify for an open source discount of 50%. Therefore they are $75/month/runner.
One "runner" should more accurately be thought of in terms of the number of vCPU you are purchasing: https://cirrus-runners.app/pricing/ or in terms of "concurrency", where 1 runners gets you 1.0 concurrency.
e.g. a Linux x86 Runner gets you
...