💬 l0rinc commented on pull request "[IBD] flush UTXO set in batches proportional to `dbcache` size":
(https://github.com/bitcoin/bitcoin/pull/31645#discussion_r2055802001)
> Capped at 256 MiB, as gains are barely measurable for bigger batches (see PR 31645)
I don't mind adding, but a simple blame would immediately reveal that
> unneeded braces line 18
They may be implied, but I want to emphasize that mathematically this isn't associative, i.e. not the same as
```C++
dbcache_bytes / (DEFAULT_KERNEL_CACHE * DEFAULT_DB_CACHE_BATCH)
```
(https://github.com/bitcoin/bitcoin/pull/31645#discussion_r2055802001)
> Capped at 256 MiB, as gains are barely measurable for bigger batches (see PR 31645)
I don't mind adding, but a simple blame would immediately reveal that
> unneeded braces line 18
They may be implied, but I want to emphasize that mathematically this isn't associative, i.e. not the same as
```C++
dbcache_bytes / (DEFAULT_KERNEL_CACHE * DEFAULT_DB_CACHE_BATCH)
```
📝 juanmigdr opened a pull request: "Add rpcestimateconservativefees"
(https://github.com/bitcoin/bitcoin/pull/32329)
### Summary
This PR introduces a new configuration option: `-rpcestimateconservativefees`. When enabled, it forces the default behavior of the `estimatesmartfee` RPC to use **conservative mode** fee estimation.
### Motivation
Bitcoin Core v28.0 changed the default fee estimation mode for `estimatesmartfee` from **conservative** to **economical** ([[#30275](https://github.com/bitcoin/bitcoin/pull/30275)](https://github.com/bitcoin/bitcoin/pull/30275)). While this change reduces fee over-
...
(https://github.com/bitcoin/bitcoin/pull/32329)
### Summary
This PR introduces a new configuration option: `-rpcestimateconservativefees`. When enabled, it forces the default behavior of the `estimatesmartfee` RPC to use **conservative mode** fee estimation.
### Motivation
Bitcoin Core v28.0 changed the default fee estimation mode for `estimatesmartfee` from **conservative** to **economical** ([[#30275](https://github.com/bitcoin/bitcoin/pull/30275)](https://github.com/bitcoin/bitcoin/pull/30275)). While this change reduces fee over-
...
💬 rkrux commented on pull request "test: fix pushdata scripts":
(https://github.com/bitcoin/bitcoin/pull/32270#discussion_r2055789608)
This is fine but seeing `pushdata1` in `tutorial/nonminpushdata1` later in the spender comment seems unnecessary then.
(https://github.com/bitcoin/bitcoin/pull/32270#discussion_r2055789608)
This is fine but seeing `pushdata1` in `tutorial/nonminpushdata1` later in the spender comment seems unnecessary then.
💬 rkrux commented on pull request "test: fix pushdata scripts":
(https://github.com/bitcoin/bitcoin/pull/32270#discussion_r2055856082)
I don't have a firm grasp on script execution yet and there are few things going on inside the "test_spenders" as well that I have not gone through in its entirety. Are following the ways these 3 tapscript scenarios executed?
1. During script execution, the empty string witness data is dropped because of "OP_DROP" and the 2 byte data is left on the stack. I'm assuming this 2 byte data counts as 1 stack item (because the stack is a vector of vector) and that's why script execution doesn't lead
...
(https://github.com/bitcoin/bitcoin/pull/32270#discussion_r2055856082)
I don't have a firm grasp on script execution yet and there are few things going on inside the "test_spenders" as well that I have not gone through in its entirety. Are following the ways these 3 tapscript scenarios executed?
1. During script execution, the empty string witness data is dropped because of "OP_DROP" and the 2 byte data is left on the stack. I'm assuming this 2 byte data counts as 1 stack item (because the stack is a vector of vector) and that's why script execution doesn't lead
...
💬 Sjors commented on pull request "refactor: inline `UndoWriteToDisk` and `WriteBlockToDisk` to reduce serialization calls":
(https://github.com/bitcoin/bitcoin/pull/31490#issuecomment-2824016734)
This PR renamed UndoReadFromDisk to ReadBlockUndo. Hopefully this comment makes this easier to find.
(https://github.com/bitcoin/bitcoin/pull/31490#issuecomment-2824016734)
This PR renamed UndoReadFromDisk to ReadBlockUndo. Hopefully this comment makes this easier to find.
💬 hodlinator commented on pull request "qa: Verify clean shutdown on startup failure":
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2055884036)
Another objection to your approach as a general rule:
If one of the lines in the happy path is modified to call a function that raises exceptions under some circumstances, we run the risk of accidentally catching it by related (parent)type through a pre-existing `except`/`catch`-block, and treating it differently than we had if we intentionally designed the code.
Side note: I'm in favor of newer languages like Rust/Zig **not** supporting exceptions.
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2055884036)
Another objection to your approach as a general rule:
If one of the lines in the happy path is modified to call a function that raises exceptions under some circumstances, we run the risk of accidentally catching it by related (parent)type through a pre-existing `except`/`catch`-block, and treating it differently than we had if we intentionally designed the code.
Side note: I'm in favor of newer languages like Rust/Zig **not** supporting exceptions.
💬 hodlinator commented on pull request "qa: Verify clean shutdown on startup failure":
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2055895552)
The forwarding of `self.options` to the child process is purely to obey the expectations of someone running feature_framework_startup_failures.py or test_runner.py with those arguments on the CLI/CI.
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2055895552)
The forwarding of `self.options` to the child process is purely to obey the expectations of someone running feature_framework_startup_failures.py or test_runner.py with those arguments on the CLI/CI.
💬 l0rinc commented on pull request "refactor: inline `UndoWriteToDisk` and `WriteBlockToDisk` to reduce serialization calls":
(https://github.com/bitcoin/bitcoin/pull/31490#issuecomment-2824055131)
yes, it was a leftover from the renames, suggested in https://github.com/bitcoin/bitcoin/pull/31490#pullrequestreview-2509562827
Did the rename cause any problems?
(https://github.com/bitcoin/bitcoin/pull/31490#issuecomment-2824055131)
yes, it was a leftover from the renames, suggested in https://github.com/bitcoin/bitcoin/pull/31490#pullrequestreview-2509562827
Did the rename cause any problems?
💬 hebasto commented on issue "PIE+LTO causes Bitcoin-Qt to segfault at startup":
(https://github.com/bitcoin-core/gui/issues/867#issuecomment-2824064676)
Is anyone aware of other distros that provide shared Qt libraries built with `-reduce-relocations`?
(asking because I'm not quite familiar with Gentoo)
Fedora, Debian/Ubuntu, and Arch do not have such an issue.
(https://github.com/bitcoin-core/gui/issues/867#issuecomment-2824064676)
Is anyone aware of other distros that provide shared Qt libraries built with `-reduce-relocations`?
(asking because I'm not quite familiar with Gentoo)
Fedora, Debian/Ubuntu, and Arch do not have such an issue.
💬 l0rinc commented on pull request "qa: Verify clean shutdown on startup failure":
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2055902833)
Not sure I understand, so is it dead code? Would the above exceptions be triggered on CI? In either case I find it confusing.
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2055902833)
Not sure I understand, so is it dead code? Would the above exceptions be triggered on CI? In either case I find it confusing.
💬 hodlinator commented on issue "ci: failure in interface_usdt_coinselection.py":
(https://github.com/bitcoin/bitcoin/issues/32322#issuecomment-2824067436)
Happened again here:
https://github.com/hodlinator/bitcoin/actions/runs/14614533923/job/40999660639#step:6:5096
(https://github.com/bitcoin/bitcoin/issues/32322#issuecomment-2824067436)
Happened again here:
https://github.com/hodlinator/bitcoin/actions/runs/14614533923/job/40999660639#step:6:5096
💬 ismaelsadeeq commented on pull request "Add rpcestimateconservativefees":
(https://github.com/bitcoin/bitcoin/pull/32329#issuecomment-2824083941)
> Bitcoin Core v28.0 changed the default fee estimation mode for `estimatesmartfee` from *conservative* to *economical* ([[#30275](https://github.com/bitcoin/bitcoin/pull/30275)](https://github.com/bitcoin/bitcoin/pull/30275)). While this change reduces fee overestimation for most users, it may not be ideal in all environments.
You can easily opt in to the `conservative` mode by passing a parameter to `estimatesmartfee`.
> In my case, I maintain a long-running node (since v24.0) with m
...
(https://github.com/bitcoin/bitcoin/pull/32329#issuecomment-2824083941)
> Bitcoin Core v28.0 changed the default fee estimation mode for `estimatesmartfee` from *conservative* to *economical* ([[#30275](https://github.com/bitcoin/bitcoin/pull/30275)](https://github.com/bitcoin/bitcoin/pull/30275)). While this change reduces fee overestimation for most users, it may not be ideal in all environments.
You can easily opt in to the `conservative` mode by passing a parameter to `estimatesmartfee`.
> In my case, I maintain a long-running node (since v24.0) with m
...
💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2055915118)
> constructing a malleated transaction wasn't as straightforward as I thought
There is `malleate_tx()` Python function in the tests. It is used by the newly added `p2p_private_broadcast.py`. It creates an invalid witness. Did you create a valid one? If yes, then maybe you want to contribute to that function, to make it possible to create valid or invalid.
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2055915118)
> constructing a malleated transaction wasn't as straightforward as I thought
There is `malleate_tx()` Python function in the tests. It is used by the newly added `p2p_private_broadcast.py`. It creates an invalid witness. Did you create a valid one? If yes, then maybe you want to contribute to that function, to make it possible to create valid or invalid.
💬 hodlinator commented on pull request "qa: Verify clean shutdown on startup failure":
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2055920502)
It is sometimes useful to debug tests by looking at what is left behind on the filesystem. In those cases one could invoke the parent with "--nocleanup". Not forwarding it to child processes means they would not leave files behind.
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2055920502)
It is sometimes useful to debug tests by looking at what is left behind on the filesystem. In those cases one could invoke the parent with "--nocleanup". Not forwarding it to child processes means they would not leave files behind.
💬 hebasto commented on issue "PIE+LTO causes Bitcoin-Qt to segfault at startup":
(https://github.com/bitcoin-core/gui/issues/867#issuecomment-2824097531)
Is anyone aware of other distros that provide shared Qt libraries built with -reduce-relocations?
(asking because I'm not quite familiar with Gentoo)
Fedora, Debian/Ubuntu, and Arch do not have such an issue.
(https://github.com/bitcoin-core/gui/issues/867#issuecomment-2824097531)
Is anyone aware of other distros that provide shared Qt libraries built with -reduce-relocations?
(asking because I'm not quite familiar with Gentoo)
Fedora, Debian/Ubuntu, and Arch do not have such an issue.
💬 thesamesam commented on issue "PIE+LTO causes Bitcoin-Qt to segfault at startup":
(https://github.com/bitcoin-core/gui/issues/867#issuecomment-2824099055)
Fedora, Debian/Ubuntu, opensuse all disable it. Arch disables it but only for Qt 5 AFAICT.
(https://github.com/bitcoin-core/gui/issues/867#issuecomment-2824099055)
Fedora, Debian/Ubuntu, opensuse all disable it. Arch disables it but only for Qt 5 AFAICT.
💬 l0rinc commented on pull request "qa: Verify clean shutdown on startup failure":
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2055927034)
Sure, but why isn't it used currently? The dead code part is what bothers me
(https://github.com/bitcoin/bitcoin/pull/30660#discussion_r2055927034)
Sure, but why isn't it used currently? The dead code part is what bothers me
💬 hebasto commented on issue "PIE+LTO causes Bitcoin-Qt to segfault at startup":
(https://github.com/bitcoin-core/gui/issues/867#issuecomment-2824107785)
> Arch disables it but only for Qt 5 AFAICT (has it enabled for Qt 6).
Building on Arch with `-flto` does not expose any runtime issues (obviously, using Qt 6).
(https://github.com/bitcoin-core/gui/issues/867#issuecomment-2824107785)
> Arch disables it but only for Qt 5 AFAICT (has it enabled for Qt 6).
Building on Arch with `-flto` does not expose any runtime issues (obviously, using Qt 6).
💬 Sjors commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-2824109607)
Opened a PR on my own fork for this: https://github.com/Sjors/bitcoin/pull/86
It's a new branch based on this one, rebased on the latest #28122, and fixes conflicts with #28358, #31483, #31490 and the introduction of CMake.
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-2824109607)
Opened a PR on my own fork for this: https://github.com/Sjors/bitcoin/pull/86
It's a new branch based on this one, rebased on the latest #28122, and fixes conflicts with #28358, #31483, #31490 and the introduction of CMake.
💬 Sjors commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#discussion_r2055934963)
I'll fix this in https://github.com/Sjors/bitcoin/pull/86
(https://github.com/bitcoin/bitcoin/pull/28241#discussion_r2055934963)
I'll fix this in https://github.com/Sjors/bitcoin/pull/86