š¬ mzumsande commented on issue "Indexes stuck on unknown best block after unclean shutdown":
(https://github.com/bitcoin/bitcoin/issues/33208#issuecomment-3198387530)
See #33212 for a fix and a test.
(https://github.com/bitcoin/bitcoin/issues/33208#issuecomment-3198387530)
See #33212 for a fix and a test.
š¬ ryanofsky commented on pull request "Add bitcoin-{node,gui} to release binaries for IPC":
(https://github.com/bitcoin/bitcoin/pull/31802#discussion_r2283445412)
re: https://github.com/bitcoin/bitcoin/pull/31802#discussion_r2283319242
I think this looks ok, although it would be nice to make the style consistent. The MATCHES checks are treating values like "@zmq_packages@" "@wallet_packages@" as false if they are empty strings or if they are "strings containing only spaces" since apparently such values are treated as false by make & depends.
The check here is doing the same thing but it's just implemented in a different way. If `@ipc_packages@` cont
...
(https://github.com/bitcoin/bitcoin/pull/31802#discussion_r2283445412)
re: https://github.com/bitcoin/bitcoin/pull/31802#discussion_r2283319242
I think this looks ok, although it would be nice to make the style consistent. The MATCHES checks are treating values like "@zmq_packages@" "@wallet_packages@" as false if they are empty strings or if they are "strings containing only spaces" since apparently such values are treated as false by make & depends.
The check here is doing the same thing but it's just implemented in a different way. If `@ipc_packages@` cont
...
š¬ achow101 commented on pull request "net, pcp: handle multi-part responses and filter for default route while querying default gateway":
(https://github.com/bitcoin/bitcoin/pull/32159#issuecomment-3198425748)
ACK 4c531782569b42fc47478a468f4a79e0e2d93946
Verified against iproute2 and strace
(https://github.com/bitcoin/bitcoin/pull/32159#issuecomment-3198425748)
ACK 4c531782569b42fc47478a468f4a79e0e2d93946
Verified against iproute2 and strace
š¬ achow101 commented on issue "Indexes stuck on unknown best block after unclean shutdown":
(https://github.com/bitcoin/bitcoin/issues/33208#issuecomment-3198474435)
> That's the sha256 hash digest of the MuHash object, not the full `MuHash3072`. I think [@mzumsande](https://github.com/mzumsande) is correct that we can't roll `m_muhash` back if the blocks are not available.
Since the coinstatsindex is changing with #30469, maybe we should also add to that to store the full muhash for every block? This would be the best time to make such a breaking change.
(https://github.com/bitcoin/bitcoin/issues/33208#issuecomment-3198474435)
> That's the sha256 hash digest of the MuHash object, not the full `MuHash3072`. I think [@mzumsande](https://github.com/mzumsande) is correct that we can't roll `m_muhash` back if the blocks are not available.
Since the coinstatsindex is changing with #30469, maybe we should also add to that to store the full muhash for every block? This would be the best time to make such a breaking change.
š¬ gmaxwell commented on pull request "net: Provide block templates to peers on request":
(https://github.com/bitcoin/bitcoin/pull/33191#issuecomment-3198534472)
The timelocks could be relaxed analogous to increasing the size however. WithMTP we essentially know the lock criteria for one block out.
I don't really think the memory usage is a concern, -- because there is just not a need to constantly do this with all peers in the face of memory pressure.
You could add an additional message that lets peers say "I have X fees in Y weight in my template" -- if the max size they were targeting was standardized then this would be a pretty good indicator w
...
(https://github.com/bitcoin/bitcoin/pull/33191#issuecomment-3198534472)
The timelocks could be relaxed analogous to increasing the size however. WithMTP we essentially know the lock criteria for one block out.
I don't really think the memory usage is a concern, -- because there is just not a need to constantly do this with all peers in the face of memory pressure.
You could add an additional message that lets peers say "I have X fees in Y weight in my template" -- if the max size they were targeting was standardized then this would be a pretty good indicator w
...
š¬ achow101 commented on pull request "test: modify logging_filesize_rate_limit params":
(https://github.com/bitcoin/bitcoin/pull/33211#issuecomment-3198536278)
If we believe it is due to the reset window, then we could set set the reset window to 5 hours, which is the longest CI timeout, so if that were to ever be reached, CI would be failing anyways. But 1 hour is also fine.
(https://github.com/bitcoin/bitcoin/pull/33211#issuecomment-3198536278)
If we believe it is due to the reset window, then we could set set the reset window to 5 hours, which is the longest CI timeout, so if that were to ever be reached, CI would be failing anyways. But 1 hour is also fine.
š¬ fjahr commented on issue "Indexes stuck on unknown best block after unclean shutdown":
(https://github.com/bitcoin/bitcoin/issues/33208#issuecomment-3198583247)
> I think @mzumsande is correct that we can't roll m_muhash back if the blocks are not available.
Actually there is a way to recover `m_muhash` but it's way too complicated to be considered as a fix IMO. Maybe in the future when we have made progress on a number of fronts. But here it goes: we could roll back the chain to the index fork point, calculate the muhash for the utxo set from scratch, compare the finalized out to the sha256 digest and then move on from there. Also, it would be possibl
...
(https://github.com/bitcoin/bitcoin/issues/33208#issuecomment-3198583247)
> I think @mzumsande is correct that we can't roll m_muhash back if the blocks are not available.
Actually there is a way to recover `m_muhash` but it's way too complicated to be considered as a fix IMO. Maybe in the future when we have made progress on a number of fronts. But here it goes: we could roll back the chain to the index fork point, calculate the muhash for the utxo set from scratch, compare the finalized out to the sha256 digest and then move on from there. Also, it would be possibl
...
š¤ achow101 reviewed a pull request: "cmake: Drop python dependency for translate"
(https://github.com/bitcoin/bitcoin/pull/33209#pullrequestreview-3130148017)
ACK d395abac85a2acf0717859f05ccfccf8a3c71a46
(https://github.com/bitcoin/bitcoin/pull/33209#pullrequestreview-3130148017)
ACK d395abac85a2acf0717859f05ccfccf8a3c71a46
š¬ murchandamus commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#issuecomment-3198841671)
> I'm not fully sold on the approach of choosing the highest value TRUC UTXO, but don't have any ideas on how to change that for this PR. Maybe @murchandamus has some thoughts on that.
Been pondering this a bit today.
- In the first pass, we will always try to fund transactions only with confirmed UTXOs. If we are just requesting a new TRUC transaction, it will always get funded by confirmed UTXOs if we have sufficient confirmed funds.
- If we are deliberately creating a child transactio
...
(https://github.com/bitcoin/bitcoin/pull/32896#issuecomment-3198841671)
> I'm not fully sold on the approach of choosing the highest value TRUC UTXO, but don't have any ideas on how to change that for this PR. Maybe @murchandamus has some thoughts on that.
Been pondering this a bit today.
- In the first pass, we will always try to fund transactions only with confirmed UTXOs. If we are just requesting a new TRUC transaction, it will always get funded by confirmed UTXOs if we have sufficient confirmed funds.
- If we are deliberately creating a child transactio
...
š¬ furszy commented on issue "Indexes stuck on unknown best block after unclean shutdown":
(https://github.com/bitcoin/bitcoin/issues/33208#issuecomment-3198876782)
> > That's the sha256 hash digest of the MuHash object, not the full `MuHash3072`. I think [@mzumsande](https://github.com/mzumsande) is correct that we can't roll `m_muhash` back if the blocks are not available.
>
> Since the coinstatsindex is changing with [#30469](https://github.com/bitcoin/bitcoin/pull/30469), maybe we should also add to that to store the full muhash for every block? This would be the best time to make such a breaking change.
I considered this, but the additional disk spac
...
(https://github.com/bitcoin/bitcoin/issues/33208#issuecomment-3198876782)
> > That's the sha256 hash digest of the MuHash object, not the full `MuHash3072`. I think [@mzumsande](https://github.com/mzumsande) is correct that we can't roll `m_muhash` back if the blocks are not available.
>
> Since the coinstatsindex is changing with [#30469](https://github.com/bitcoin/bitcoin/pull/30469), maybe we should also add to that to store the full muhash for every block? This would be the best time to make such a breaking change.
I considered this, but the additional disk spac
...
š fqlx opened a pull request: "rpc: require integer verbosity; remove boolean 'verbose'"
(https://github.com/bitcoin/bitcoin/pull/33213)
### Summary
Standardize RPC verbosity to integers only and remove boolean handling for clarity, consistency, and future extensibility.
### Rationale
- **Legacy cleanup**: Boolean verbosity has been discouraged/deprecated in docs since 2017 and continues to create tech debt (special-case parsing, inconsistent tests, user confusion).
- **Consistency**: Integers enable multi-level output without overloading a boolean.
### User-visible changes
- getblock, getrawtransaction, getrawmemp
...
(https://github.com/bitcoin/bitcoin/pull/33213)
### Summary
Standardize RPC verbosity to integers only and remove boolean handling for clarity, consistency, and future extensibility.
### Rationale
- **Legacy cleanup**: Boolean verbosity has been discouraged/deprecated in docs since 2017 and continues to create tech debt (special-case parsing, inconsistent tests, user confusion).
- **Consistency**: Integers enable multi-level output without overloading a boolean.
### User-visible changes
- getblock, getrawtransaction, getrawmemp
...
š¬ fqlx commented on pull request "rpc: require integer verbosity; remove boolean 'verbose'":
(https://github.com/bitcoin/bitcoin/pull/33213#issuecomment-3198968576)
@DrahtBot Can you reopen?
(https://github.com/bitcoin/bitcoin/pull/33213#issuecomment-3198968576)
@DrahtBot Can you reopen?
š¬ fqlx commented on pull request "rpc: require integer verbosity; remove boolean 'verbose'":
(https://github.com/bitcoin/bitcoin/pull/33213#issuecomment-3198997112)
Hi @fanquake @glozow @achow101 @hebasto ā DrahtBot auto-closed this, but Iād like to request a reopen.
This PR removes legacy boolean verbosity and standardizes integer verbosity across RPCs (deprecated since 2017), updates docs/tests, and includes release notes. Happy to split if needed. Thanks!
(https://github.com/bitcoin/bitcoin/pull/33213#issuecomment-3198997112)
Hi @fanquake @glozow @achow101 @hebasto ā DrahtBot auto-closed this, but Iād like to request a reopen.
This PR removes legacy boolean verbosity and standardizes integer verbosity across RPCs (deprecated since 2017), updates docs/tests, and includes release notes. Happy to split if needed. Thanks!
š fqlx opened a pull request: "Rpc no bool verbosity"
(https://github.com/bitcoin/bitcoin/pull/33214)
### Summary
Standardize RPC verbosity to integers only and remove boolean handling for clarity, consistency, and future extensibility.
### Rationale
- **Legacy cleanup**: Boolean verbosity has been discouraged/deprecated in docs since 2017 and continues to create tech debt (special-case parsing, inconsistent tests, user confusion).
- **Consistency**: Integers enable multi-level output without overloading a boolean.
### User-visible changes
- getblock, getrawtransaction, getrawmemp
...
(https://github.com/bitcoin/bitcoin/pull/33214)
### Summary
Standardize RPC verbosity to integers only and remove boolean handling for clarity, consistency, and future extensibility.
### Rationale
- **Legacy cleanup**: Boolean verbosity has been discouraged/deprecated in docs since 2017 and continues to create tech debt (special-case parsing, inconsistent tests, user confusion).
- **Consistency**: Integers enable multi-level output without overloading a boolean.
### User-visible changes
- getblock, getrawtransaction, getrawmemp
...
š¤ hebasto reviewed a pull request: "cmake: Drop python dependency for translate"
(https://github.com/bitcoin/bitcoin/pull/33209#pullrequestreview-3131093710)
I have reviewed d395abac85a2acf0717859f05ccfccf8a3c71a46.
> Changes:
>
> * xgettext is instructed to sort the output by file
>
> * the messages are no longer sorted by cmake
Could we revert these changes? All strings in `src/qt/bitcoinstrings.cpp` sahre the same context, namely "bitcoin-core". Keeping the content stable by sorting within the context feels more natural. Otherwise, the string order depends on the order in which source files are processed by `xgettext`.
> *
...
(https://github.com/bitcoin/bitcoin/pull/33209#pullrequestreview-3131093710)
I have reviewed d395abac85a2acf0717859f05ccfccf8a3c71a46.
> Changes:
>
> * xgettext is instructed to sort the output by file
>
> * the messages are no longer sorted by cmake
Could we revert these changes? All strings in `src/qt/bitcoinstrings.cpp` sahre the same context, namely "bitcoin-core". Keeping the content stable by sorting within the context feels more natural. Otherwise, the string order depends on the order in which source files are processed by `xgettext`.
> *
...
š¬ hebasto commented on pull request "Release: Prepare "Open Transifex translations for v30.0" step":
(https://github.com/bitcoin/bitcoin/pull/33152#issuecomment-3199595855)
@laanwj
> Last commit reproduces also on Ubuntu 24.04, with only harmless differences in C string splitting like
>
> ```
> "Outbound connections restricted to CJDNS (-onlynet=cjdns) but "
> "-cjdnsreachable is not provided"),
...
(https://github.com/bitcoin/bitcoin/pull/33152#issuecomment-3199595855)
@laanwj
> Last commit reproduces also on Ubuntu 24.04, with only harmless differences in C string splitting like
>
> ```
> "Outbound connections restricted to CJDNS (-onlynet=cjdns) but "
> "-cjdnsreachable is not provided"),
...
š¬ hebasto commented on pull request "cmake: Drop python dependency for translate":
(https://github.com/bitcoin/bitcoin/pull/33209#issuecomment-3199647537)
@purpleKarrot
> Translate the `share/qt/extract_strings_qt.py` script to CMake. This removes the python dependency from the `translate` target.
Mind updating the PR description with something like "Resolves #33146"?
(https://github.com/bitcoin/bitcoin/pull/33209#issuecomment-3199647537)
@purpleKarrot
> Translate the `share/qt/extract_strings_qt.py` script to CMake. This removes the python dependency from the `translate` target.
Mind updating the PR description with something like "Resolves #33146"?
š¬ purpleKarrot commented on pull request "cmake: Drop python dependency for translate":
(https://github.com/bitcoin/bitcoin/pull/33209#issuecomment-3199648782)
> Otherwise, the string order depends on the order in which source files are processed by `xgettext`.
@hebasto, I just created two files `a.c` and `b.c` with some `gettext` content and compared the outputs of `xgettext a.c b.c` and `xgettext b.c a.c` both with `--sort-by-file` and without. I can confirm that without the `--sort-by-file` option the order of processing changes the output, but it is stable when that option is used.
(https://github.com/bitcoin/bitcoin/pull/33209#issuecomment-3199648782)
> Otherwise, the string order depends on the order in which source files are processed by `xgettext`.
@hebasto, I just created two files `a.c` and `b.c` with some `gettext` content and compared the outputs of `xgettext a.c b.c` and `xgettext b.c a.c` both with `--sort-by-file` and without. I can confirm that without the `--sort-by-file` option the order of processing changes the output, but it is stable when that option is used.
š¬ hebasto commented on pull request "cmake: Drop python dependency for translate":
(https://github.com/bitcoin/bitcoin/pull/33209#issuecomment-3199693425)
> > Otherwise, the string order depends on the order in which source files are processed by `xgettext`.
>
> @hebasto, I just created two files `a.c` and `b.c` with some `gettext` content and compared the outputs of `xgettext a.c b.c` and `xgettext b.c a.c` both with `--sort-by-file` and without. I can confirm that without the `--sort-by-file` option the order of processing changes the output, but it is stable when that option is used.
Right my assumption was not correct.
However, there
...
(https://github.com/bitcoin/bitcoin/pull/33209#issuecomment-3199693425)
> > Otherwise, the string order depends on the order in which source files are processed by `xgettext`.
>
> @hebasto, I just created two files `a.c` and `b.c` with some `gettext` content and compared the outputs of `xgettext a.c b.c` and `xgettext b.c a.c` both with `--sort-by-file` and without. I can confirm that without the `--sort-by-file` option the order of processing changes the output, but it is stable when that option is used.
Right my assumption was not correct.
However, there
...
š hebasto approved a pull request: "cmake: Drop python dependency for translate"
(https://github.com/bitcoin/bitcoin/pull/33209#pullrequestreview-3131218780)
ACK 3c4a109aa821cbf1e46a67275b4f456673ed13d8.
(https://github.com/bitcoin/bitcoin/pull/33209#pullrequestreview-3131218780)
ACK 3c4a109aa821cbf1e46a67275b4f456673ed13d8.