💬 fjahr commented on issue "wallet RPC to double-check the calculated balance":
(https://github.com/bitcoin/bitcoin/issues/28898#issuecomment-1824766692)
Allowing to call `importdescriptors` with the same descriptor but a different birthdate may also be a solution? Are users only interested in spendable outputs or may they also be interested in their transaction history in general?
(https://github.com/bitcoin/bitcoin/issues/28898#issuecomment-1824766692)
Allowing to call `importdescriptors` with the same descriptor but a different birthdate may also be a solution? Are users only interested in spendable outputs or may they also be interested in their transaction history in general?
💬 fjahr commented on pull request "wallet: Add checkbalance RPC":
(https://github.com/bitcoin/bitcoin/pull/28930#issuecomment-1824766969)
I think I would prefer the other option @maflcko suggested in the issue, i.e. adding a `check` flag to `getbalances`.
(https://github.com/bitcoin/bitcoin/pull/28930#issuecomment-1824766969)
I think I would prefer the other option @maflcko suggested in the issue, i.e. adding a `check` flag to `getbalances`.
🚀 fanquake merged a pull request: "test: Add gettransaction test for "coin-join" tx"
(https://github.com/bitcoin/bitcoin/pull/18919)
(https://github.com/bitcoin/bitcoin/pull/18919)
📝 fanquake opened a pull request: "ci: remove `python3-setuptools` from macOS build deps"
(https://github.com/bitcoin/bitcoin/pull/28932)
Remove no-longer used python-setuptools.
Followup to #28432.
Related to #28845.
(https://github.com/bitcoin/bitcoin/pull/28932)
Remove no-longer used python-setuptools.
Followup to #28432.
Related to #28845.
💬 fanquake commented on pull request "Fix SSE4.1-related issues":
(https://github.com/bitcoin/bitcoin/pull/28893#issuecomment-1824780061)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/28893#issuecomment-1824780061)
Concept ACK
💬 lrs955 commented on pull request "blockstorage: XOR blocksdir *.dat files":
(https://github.com/bitcoin/bitcoin/pull/28052#issuecomment-1824797551)
> > why not save the xor key inside the leveldb block database?
>
> Just seems more complicated with no benefit?
I understand.
Maybe im wrong but isn't also the xor pattern of the chainstate saved in the database itself? Different leveldb database but still in a key a database.
(https://github.com/bitcoin/bitcoin/pull/28052#issuecomment-1824797551)
> > why not save the xor key inside the leveldb block database?
>
> Just seems more complicated with no benefit?
I understand.
Maybe im wrong but isn't also the xor pattern of the chainstate saved in the database itself? Different leveldb database but still in a key a database.
👍 hebasto approved a pull request: "ci: remove `python3-setuptools` from macOS build deps"
(https://github.com/bitcoin/bitcoin/pull/28932#pullrequestreview-1746941879)
ACK 0ffcc5b680b92cf921fc11afb05e4a3607572d41, I have reviewed the code and it looks OK.
(https://github.com/bitcoin/bitcoin/pull/28932#pullrequestreview-1746941879)
ACK 0ffcc5b680b92cf921fc11afb05e4a3607572d41, I have reviewed the code and it looks OK.
💬 furszy commented on issue "wallet RPC to double-check the calculated balance":
(https://github.com/bitcoin/bitcoin/issues/28898#issuecomment-1824916723)
An alternative/parallel course of action could be making `rescanblockchain` much faster. Removing the need for users to make an additional RPC command to identify any missing tx.
<start_shill>
The user can build the block filter index in 5-10 minutes using #26966 (per Sjors's benchmark). And, with it, `rescanblockchain` performs at a completely different speed level.
<end_shill>
(https://github.com/bitcoin/bitcoin/issues/28898#issuecomment-1824916723)
An alternative/parallel course of action could be making `rescanblockchain` much faster. Removing the need for users to make an additional RPC command to identify any missing tx.
<start_shill>
The user can build the block filter index in 5-10 minutes using #26966 (per Sjors's benchmark). And, with it, `rescanblockchain` performs at a completely different speed level.
<end_shill>
👍 TheCharlatan approved a pull request: "wallet: propagete `checkChainLimits` error message to wallet"
(https://github.com/bitcoin/bitcoin/pull/28863#pullrequestreview-1747036936)
ACK bd5417e47cd2452817d7de859839b63210233a5c
(https://github.com/bitcoin/bitcoin/pull/28863#pullrequestreview-1747036936)
ACK bd5417e47cd2452817d7de859839b63210233a5c
💬 sipa commented on pull request "Fix SSE4.1-related issues":
(https://github.com/bitcoin/bitcoin/pull/28893#issuecomment-1824956649)
Concept ACK (if happy CI)
(https://github.com/bitcoin/bitcoin/pull/28893#issuecomment-1824956649)
Concept ACK (if happy CI)
💬 furszy commented on pull request "wallet: propagete `checkChainLimits` error message to wallet":
(https://github.com/bitcoin/bitcoin/pull/28863#discussion_r1403766480)
Not blocking.
Could return `util::Result<void>` and inline all the `err_string` return messages within the `CheckPackageLimits` function.
(https://github.com/bitcoin/bitcoin/pull/28863#discussion_r1403766480)
Not blocking.
Could return `util::Result<void>` and inline all the `err_string` return messages within the `CheckPackageLimits` function.
💬 achow101 commented on issue "importing a wallet containing an hdseed overwrites target wallet hdseed":
(https://github.com/bitcoin/bitcoin/issues/28927#issuecomment-1825170183)
`importwallet` does not import any metadata, including whether something is the seed. That it overwrites the seed metadata is expected behavior, although it should still work as the seed. You can check whether both wallets use the same seed by looking at `hdseedid` in `getwalletinfo`, and also generating some addresses to see if both wallets recognize them with `getaddressinfo`.
However, the workflow that you are using uses the legacy wallet storage format which is targeted to be removed soon
...
(https://github.com/bitcoin/bitcoin/issues/28927#issuecomment-1825170183)
`importwallet` does not import any metadata, including whether something is the seed. That it overwrites the seed metadata is expected behavior, although it should still work as the seed. You can check whether both wallets use the same seed by looking at `hdseedid` in `getwalletinfo`, and also generating some addresses to see if both wallets recognize them with `getaddressinfo`.
However, the workflow that you are using uses the legacy wallet storage format which is targeted to be removed soon
...
💬 Daniel600 commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1825182273)
> @Daniel600
>
> > At GAP600 to date we have not seen any significant impact of FULLRBF on our service - we have seen circa 2 trxs which affected us, keep in mind we processed Circa 180k unique trx hash in Sept of 2023.
>
> Have you actually tested full-RBF double spends against your service? Because at the moment, about 40% of hash power is mining with full-RBF enabled. So the chance of a full-RBF double-spend succeeding is approximately 40%.
>
> As an example, here in El Salvador the
...
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1825182273)
> @Daniel600
>
> > At GAP600 to date we have not seen any significant impact of FULLRBF on our service - we have seen circa 2 trxs which affected us, keep in mind we processed Circa 180k unique trx hash in Sept of 2023.
>
> Have you actually tested full-RBF double spends against your service? Because at the moment, about 40% of hash power is mining with full-RBF enabled. So the chance of a full-RBF double-spend succeeding is approximately 40%.
>
> As an example, here in El Salvador the
...
💬 quakemmo commented on issue "importing a wallet containing an hdseed overwrites target wallet hdseed":
(https://github.com/bitcoin/bitcoin/issues/28927#issuecomment-1825262967)
@achow101 Thank you for your reply.
Can you please point me to the right direction as far as the "proper workflow" is concerned? My basic need is to have two nodes that I can failover between in case one goes down, with no coin loss (obviously) and reasonable downtime.
The nodes will be used for a classic mechanism of receiving user deposits (each user has its own BTC address), and sending withdrawals using "sendtoaddress" at first, then using raw transactions when I implement that. I pre
...
(https://github.com/bitcoin/bitcoin/issues/28927#issuecomment-1825262967)
@achow101 Thank you for your reply.
Can you please point me to the right direction as far as the "proper workflow" is concerned? My basic need is to have two nodes that I can failover between in case one goes down, with no coin loss (obviously) and reasonable downtime.
The nodes will be used for a classic mechanism of receiving user deposits (each user has its own BTC address), and sending withdrawals using "sendtoaddress" at first, then using raw transactions when I implement that. I pre
...
👍 TheCharlatan approved a pull request: "ci: remove `python3-setuptools` from macOS build deps"
(https://github.com/bitcoin/bitcoin/pull/28932#pullrequestreview-1747457083)
ACK 0ffcc5b680b92cf921fc11afb05e4a3607572d41
(https://github.com/bitcoin/bitcoin/pull/28932#pullrequestreview-1747457083)
ACK 0ffcc5b680b92cf921fc11afb05e4a3607572d41
💬 naumenkogs commented on pull request "p2p: Fill reconciliation sets (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/28765#discussion_r1404092298)
Improved the documentation around it a bit.
(https://github.com/bitcoin/bitcoin/pull/28765#discussion_r1404092298)
Improved the documentation around it a bit.
💬 naumenkogs commented on pull request "p2p: Fill reconciliation sets (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/28765#issuecomment-1825334360)
Addressed the comments, mostly refactoring. Some conversations pending above. The code is good for review.
(https://github.com/bitcoin/bitcoin/pull/28765#issuecomment-1825334360)
Addressed the comments, mostly refactoring. Some conversations pending above. The code is good for review.
💬 maflcko commented on issue "wallet RPC to double-check the calculated balance":
(https://github.com/bitcoin/bitcoin/issues/28898#issuecomment-1825338315)
> An alternative/parallel course of action could be making `rescanblockchain` much faster. Removing the need for additional RPC calls to identify any missing tx.
I don't think this is an alternative, because the rescan won't find the txs if the birthdate is wrong, see also https://github.com/bitcoin/bitcoin/issues/28897? Moreover, on hardware without parallel cores, building the block filter index is not going to be sped up. Finally, on wallets with a sufficient number of keys, the blockfilte
...
(https://github.com/bitcoin/bitcoin/issues/28898#issuecomment-1825338315)
> An alternative/parallel course of action could be making `rescanblockchain` much faster. Removing the need for additional RPC calls to identify any missing tx.
I don't think this is an alternative, because the rescan won't find the txs if the birthdate is wrong, see also https://github.com/bitcoin/bitcoin/issues/28897? Moreover, on hardware without parallel cores, building the block filter index is not going to be sped up. Finally, on wallets with a sufficient number of keys, the blockfilte
...
💬 naumenkogs commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1404107883)
good point.
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1404107883)
good point.
💬 naumenkogs commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1404108378)
well, actually....you still can track it with a map<addr, bool>, no?
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1404108378)
well, actually....you still can track it with a map<addr, bool>, no?
👍 dergoegge approved a pull request: "fuzz: Limit fuzz buffer size in script_flags target"
(https://github.com/bitcoin/bitcoin/pull/28931#pullrequestreview-1747698896)
ACK faf1fb207fb6e9a12c864074f8c40d5922d93ff4
(https://github.com/bitcoin/bitcoin/pull/28931#pullrequestreview-1747698896)
ACK faf1fb207fb6e9a12c864074f8c40d5922d93ff4