š¬ hebasto commented on pull request "test: Suppress Windows abort message in CI":
(https://github.com/bitcoin/bitcoin/pull/32409#discussion_r2081956577)
> Is it a bug in mingw-w64 that it doesn't match the MSVC behaviour?
I don't think so, given the different runtime libraries used. I must admit I haven't tested cross-compiled binaries linked to UCRT.
(https://github.com/bitcoin/bitcoin/pull/32409#discussion_r2081956577)
> Is it a bug in mingw-w64 that it doesn't match the MSVC behaviour?
I don't think so, given the different runtime libraries used. I must admit I haven't tested cross-compiled binaries linked to UCRT.
ā ļø ismaelsadeeq opened an issue: "RFC: Should node Wallet Startup Options Apply to Individual Wallets?"
(https://github.com/bitcoin/bitcoin/issues/32462)
PR #29278 is going to introduces a `maxfeerate` wallet startup option.
There was some discussion between between @luke-jr , me, and @murchandamus in a thread https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1468533274
> This still isn't a wallet option...
> I don't understand why you said it is not a wallet option.
> The `OptionsCategory` of this startup option is `WALLET`, and it's only used in the wallet.
> Can you please expand on your comment?
> Thanks.
> Iām also confused by t
...
(https://github.com/bitcoin/bitcoin/issues/32462)
PR #29278 is going to introduces a `maxfeerate` wallet startup option.
There was some discussion between between @luke-jr , me, and @murchandamus in a thread https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1468533274
> This still isn't a wallet option...
> I don't understand why you said it is not a wallet option.
> The `OptionsCategory` of this startup option is `WALLET`, and it's only used in the wallet.
> Can you please expand on your comment?
> Thanks.
> Iām also confused by t
...
š¬ ismaelsadeeq commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r2081959909)
I opened a separate issue for this here https://github.com/bitcoin/bitcoin/issues/32462#issue-3052551984
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r2081959909)
I opened a separate issue for this here https://github.com/bitcoin/bitcoin/issues/32462#issue-3052551984
š¬ l0rinc commented on pull request "bench: replace benchmark block with more representative one (413567 ā 784588)":
(https://github.com/bitcoin/bitcoin/pull/32457#discussion_r2081962158)
Understandable, but that's why I added the hashes here, to make it self-validating.
(https://github.com/bitcoin/bitcoin/pull/32457#discussion_r2081962158)
Understandable, but that's why I added the hashes here, to make it self-validating.
š fanquake merged a pull request: "refactor: Removals after bdb removal"
(https://github.com/bitcoin/bitcoin/pull/32438)
(https://github.com/bitcoin/bitcoin/pull/32438)
š¬ hebasto commented on pull request "test: Suppress Windows abort message in CI":
(https://github.com/bitcoin/bitcoin/pull/32409#issuecomment-2867062653)
> > It is documented, and it is pre-defined by CI itself:
>
> It's not in our docs, or in our CI code, which means our CI would "work", because a third party is putting something into the environment, and the fact that this is even happening, is only discoverable if you happen to read a `.cpp` file.
What are you suggesting should be changed to improve or avoid this situation?
> Would someone running these binaries locally also need/want to set this env var to get the same behaviour? If
...
(https://github.com/bitcoin/bitcoin/pull/32409#issuecomment-2867062653)
> > It is documented, and it is pre-defined by CI itself:
>
> It's not in our docs, or in our CI code, which means our CI would "work", because a third party is putting something into the environment, and the fact that this is even happening, is only discoverable if you happen to read a `.cpp` file.
What are you suggesting should be changed to improve or avoid this situation?
> Would someone running these binaries locally also need/want to set this env var to get the same behaviour? If
...
š¬ fanquake commented on pull request "test: Suppress Windows abort message in CI":
(https://github.com/bitcoin/bitcoin/pull/32409#issuecomment-2867064817)
> This does not apply to the "raw" GitHub Actions workflows, where this code takes effect.
Can't someone just compile and run the same binaries locally?
(https://github.com/bitcoin/bitcoin/pull/32409#issuecomment-2867064817)
> This does not apply to the "raw" GitHub Actions workflows, where this code takes effect.
Can't someone just compile and run the same binaries locally?
š¬ hebasto commented on pull request "test: Suppress Windows abort message in CI":
(https://github.com/bitcoin/bitcoin/pull/32409#issuecomment-2867073689)
> > This does not apply to the "raw" GitHub Actions workflows, where this code takes effect.
>
> Can't someone just compile and run the same binaries locally?
Certainly, they can. But displaying a message box isn't an issue when running binaries locally, so there's no need to alter the environment in that case.
(https://github.com/bitcoin/bitcoin/pull/32409#issuecomment-2867073689)
> > This does not apply to the "raw" GitHub Actions workflows, where this code takes effect.
>
> Can't someone just compile and run the same binaries locally?
Certainly, they can. But displaying a message box isn't an issue when running binaries locally, so there's no need to alter the environment in that case.
š¤ pablomartin4btc reviewed a pull request: "wallet: init, don't error out when loading legacy wallets"
(https://github.com/bitcoin/bitcoin/pull/32449#pullrequestreview-2828866727)
Concept ACK
You could have a few/ several legacy wallets on the `settings.json`. Perhaps list them all together on a warning or just warn that there is at least one (on the GUI you would get a pop up on each otherwise).
(https://github.com/bitcoin/bitcoin/pull/32449#pullrequestreview-2828866727)
Concept ACK
You could have a few/ several legacy wallets on the `settings.json`. Perhaps list them all together on a warning or just warn that there is at least one (on the GUI you would get a pop up on each otherwise).
š¬ pablomartin4btc commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#discussion_r2081981059)
_<ins>nit</ins>_: it's not a failure on a load, it's not allowed/ possible anymore... just a suggestion, could be another text message... (also checking a flag to send the warning only once... or with the list of all of them if many)
```suggestion
warnings.push_back(strprintf(_("There are legacy wallets in settings.json which are no longer supported.\n\nPlease migrate to a descriptor wallet using the migration tool (migratewallet RPC or the GUI option)."), walletFile));
```
(https://github.com/bitcoin/bitcoin/pull/32449#discussion_r2081981059)
_<ins>nit</ins>_: it's not a failure on a load, it's not allowed/ possible anymore... just a suggestion, could be another text message... (also checking a flag to send the warning only once... or with the list of all of them if many)
```suggestion
warnings.push_back(strprintf(_("There are legacy wallets in settings.json which are no longer supported.\n\nPlease migrate to a descriptor wallet using the migration tool (migratewallet RPC or the GUI option)."), walletFile));
```
š¬ hebasto commented on pull request "test: Suppress Windows abort message in CI":
(https://github.com/bitcoin/bitcoin/pull/32409#issuecomment-2867088113)
As an alternative, we could explicitly set our own `SUPPRESS_ABORT_MESSAGE_BOX` environment variable in the workflow, and gate the code with this variable instead, removing the `#if defined(_MSC_VER)` condition.
(https://github.com/bitcoin/bitcoin/pull/32409#issuecomment-2867088113)
As an alternative, we could explicitly set our own `SUPPRESS_ABORT_MESSAGE_BOX` environment variable in the workflow, and gate the code with this variable instead, removing the `#if defined(_MSC_VER)` condition.
š¬ laanwj commented on pull request "fs: remove `_POSIX_C_SOURCE` defining":
(https://github.com/bitcoin/bitcoin/pull/32460#issuecomment-2867090172)
> From what I can tell, compilers on Linux systems, will be defining _GNU_SOURCE, which results in glibc defining _POSIX_C_SOURCE to 200809L; so undefining it, and setting it to an earlier value does not seem like the correct behaviour for us, or even required
Yes, there is never a valid reason to set it to a lower value. The idea of the macro is to tell the header files "i know about POSIX version X and want to use it".
Usually this is defined by the build system, or at most at the top of
...
(https://github.com/bitcoin/bitcoin/pull/32460#issuecomment-2867090172)
> From what I can tell, compilers on Linux systems, will be defining _GNU_SOURCE, which results in glibc defining _POSIX_C_SOURCE to 200809L; so undefining it, and setting it to an earlier value does not seem like the correct behaviour for us, or even required
Yes, there is never a valid reason to set it to a lower value. The idea of the macro is to tell the header files "i know about POSIX version X and want to use it".
Usually this is defined by the build system, or at most at the top of
...
š¬ ismaelsadeeq commented on pull request "interfaces: refactor: move `Mining` and `BlockTemplate` implementation to miner":
(https://github.com/bitcoin/bitcoin/pull/32378#discussion_r2082064876)
Fixed
(https://github.com/bitcoin/bitcoin/pull/32378#discussion_r2082064876)
Fixed
š¬ ismaelsadeeq commented on pull request "interfaces: refactor: move `Mining` and `BlockTemplate` implementation to miner":
(https://github.com/bitcoin/bitcoin/pull/32378#discussion_r2082066284)
Taken, thanks
(https://github.com/bitcoin/bitcoin/pull/32378#discussion_r2082066284)
Taken, thanks
š¬ ismaelsadeeq commented on pull request "interfaces: refactor: move `Mining` and `BlockTemplate` implementation to miner":
(https://github.com/bitcoin/bitcoin/pull/32378#issuecomment-2867201958)
Forced pushed to address recent comments see [c8a3fabe..31e3808d](https://github.com/bitcoin/bitcoin/compare/c8a3fabe4090fa2b9a0e8cef73ed5365e8221ad6..31e3808df9c59d36a07cad07df89ae1bf9e63000)
(https://github.com/bitcoin/bitcoin/pull/32378#issuecomment-2867201958)
Forced pushed to address recent comments see [c8a3fabe..31e3808d](https://github.com/bitcoin/bitcoin/compare/c8a3fabe4090fa2b9a0e8cef73ed5365e8221ad6..31e3808df9c59d36a07cad07df89ae1bf9e63000)
š¬ laanwj commented on pull request "bench: replace benchmark block with more representative one (413567 ā 784588)":
(https://github.com/bitcoin/bitcoin/pull/32457#discussion_r2082115539)
Hahaha agree it would be extremely far-fetched to put data in a specific block, just to add it in the repository two years later.
(https://github.com/bitcoin/bitcoin/pull/32457#discussion_r2082115539)
Hahaha agree it would be extremely far-fetched to put data in a specific block, just to add it in the repository two years later.
š ismaelsadeeq opened a pull request: "test: fix an incorrect `feature_fee_estimation.py` subtest"
(https://github.com/bitcoin/bitcoin/pull/32463)
Attempt to fix #32461
In the `estimatesmartfee` RPC, we return the maximum of the following: the feerate estimate for the target, `minrelaytxfee`, and `mempoolminfee`.
https://github.com/bitcoin/bitcoin/blob/9a05b45da60d214cb1e5a50c3d2293b1defc9bb0/src/rpc/fees.cpp#L85
The test `test_feerate_mempoolminfee`, originally introduced in https://github.com/bitcoin/bitcoin/commit/ea31caf6b4c182c6f10f136548f84e603800511c, is incorrect.
It should append the higher value used to start the node
...
(https://github.com/bitcoin/bitcoin/pull/32463)
Attempt to fix #32461
In the `estimatesmartfee` RPC, we return the maximum of the following: the feerate estimate for the target, `minrelaytxfee`, and `mempoolminfee`.
https://github.com/bitcoin/bitcoin/blob/9a05b45da60d214cb1e5a50c3d2293b1defc9bb0/src/rpc/fees.cpp#L85
The test `test_feerate_mempoolminfee`, originally introduced in https://github.com/bitcoin/bitcoin/commit/ea31caf6b4c182c6f10f136548f84e603800511c, is incorrect.
It should append the higher value used to start the node
...
š¬ ismaelsadeeq commented on issue "test: `acceptstalefeeestimates` failure in `feature_fee_estimation` after duplicate coinbase tx weight reservation fix":
(https://github.com/bitcoin/bitcoin/issues/32461#issuecomment-2867564112)
@l0rinc Thanks for the thorough report.
However, the failure is not in the `acceptstalefeeestimates` subtest, but in `test_feerate_mempoolminfee`.
I believe the issue is that we are not appending `high_val` to `self.fees_per_kb` before checking the estimates.
I attempted to fix this in #32463.
---
Also, it's quite strange that the test started failing on this commit https://github.com/bitcoin/bitcoin/commit/6b165f5906fc53bd10bedff85a6ef26e0aabdc5c
I haven't looked into that yet.
(https://github.com/bitcoin/bitcoin/issues/32461#issuecomment-2867564112)
@l0rinc Thanks for the thorough report.
However, the failure is not in the `acceptstalefeeestimates` subtest, but in `test_feerate_mempoolminfee`.
I believe the issue is that we are not appending `high_val` to `self.fees_per_kb` before checking the estimates.
I attempted to fix this in #32463.
---
Also, it's quite strange that the test started failing on this commit https://github.com/bitcoin/bitcoin/commit/6b165f5906fc53bd10bedff85a6ef26e0aabdc5c
I haven't looked into that yet.
š¬ achow101 commented on pull request "test: Remove legacy wallet RPC overloads":
(https://github.com/bitcoin/bitcoin/pull/32452#issuecomment-2867645207)
Fixed the linter and reorganized as suggested.
(https://github.com/bitcoin/bitcoin/pull/32452#issuecomment-2867645207)
Fixed the linter and reorganized as suggested.
š¬ l0rinc commented on pull request "test: fix an incorrect `feature_fee_estimation.py` subtest":
(https://github.com/bitcoin/bitcoin/pull/32463#issuecomment-2867652250)
Thanks for fixing it so quickly, I can confirm that this fixes the test for the failing `--random=3450808900320758527`.
Someone more knowledgeable in this area of the code should also look at at, but from my part it's a lightweight ACK.
ACK 2c5f26bc6ac47e3a6a8555e9a6c60832322a36e8
(https://github.com/bitcoin/bitcoin/pull/32463#issuecomment-2867652250)
Thanks for fixing it so quickly, I can confirm that this fixes the test for the failing `--random=3450808900320758527`.
Someone more knowledgeable in this area of the code should also look at at, but from my part it's a lightweight ACK.
ACK 2c5f26bc6ac47e3a6a8555e9a6c60832322a36e8