💬 andrewtoth commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094232479)
Done.
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094232479)
Done.
💬 andrewtoth commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094232512)
Fixed, we don't overwrite the key now if we didn't create a new one. We also call `sync_data` after writing the new random one.
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094232512)
Fixed, we don't overwrite the key now if we didn't create a new one. We also call `sync_data` after writing the new random one.
💬 andrewtoth commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094232615)
Done. We just use `read` now.
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094232615)
Done. We just use `read` now.
💬 andrewtoth commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094232624)
Done.
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094232624)
Done.
💬 andrewtoth commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094235373)
I have unfortunately not tested on Windows. If anyone could test I would be grateful. If this is the wrong home dir though then a user can just specify it manually using the `-datadir=` option.
It seems this function will be undeprecated in a future release https://github.com/rust-lang/rust/issues/132650.
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094235373)
I have unfortunately not tested on Windows. If anyone could test I would be grateful. If this is the wrong home dir though then a user can just specify it manually using the `-datadir=` option.
It seems this function will be undeprecated in a future release https://github.com/rust-lang/rust/issues/132650.
💬 andrewtoth commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094235788)
I added checking for `-datadir=` and `--datadir=`, but not `datadir=` or `---datadir=`. Just like `bitcoind` :).
> I'd like to see here is having proper usage page if no arguments are provided
If no args are provided, it just picks up the default datadir. IMO that's the best behavior. If you give more than 1 arg it prints out a usage instruction as an error.
Is that what you had in mind?
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094235788)
I added checking for `-datadir=` and `--datadir=`, but not `datadir=` or `---datadir=`. Just like `bitcoind` :).
> I'd like to see here is having proper usage page if no arguments are provided
If no args are provided, it just picks up the default datadir. IMO that's the best behavior. If you give more than 1 arg it prints out a usage instruction as an error.
Is that what you had in mind?
💬 andrewtoth commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094235834)
Done. I went one further and use Rust's `u128`, so we double the key and xor 16 bytes at a time.
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2094235834)
Done. I went one further and use Rust's `u128`, so we double the key and xor 16 bytes at a time.
💬 andrewtoth commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#issuecomment-2888632586)
> Consider obtaining the .lock file in the data directory in the same way bitcoind does. This will prevent bitcoind from starting if this tool is running, and vice versa.
@LarryRuane great suggestion. Unfortunately file locking is still experimental in Rust (?), so users would have to run nightly to be able to run the program. I think we should wait until it's stabilized instead of pulling in third party deps to do the locking.
> It seems better if we track the height at which xor starts
...
(https://github.com/bitcoin/bitcoin/pull/32451#issuecomment-2888632586)
> Consider obtaining the .lock file in the data directory in the same way bitcoind does. This will prevent bitcoind from starting if this tool is running, and vice versa.
@LarryRuane great suggestion. Unfortunately file locking is still experimental in Rust (?), so users would have to run nightly to be able to run the program. I think we should wait until it's stabilized instead of pulling in third party deps to do the locking.
> It seems better if we track the height at which xor starts
...
📝 sipa opened a pull request: "Replace cluster linearization algorithm with SFL"
(https://github.com/bitcoin/bitcoin/pull/32545)
This replaces the cluster linearization algorithm introduced in #30286 (a combination of LIMO with candidate-set search), with a completely different algorithm: ([spanning-forest linearization](https://delvingbitcoin.org/t/spanning-forest-cluster-linearization/1419/1)), which appears to have much better performance for hard clusters. See [this post](https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68) for a comparison between various linearization algorithms, and [this post](https:
...
(https://github.com/bitcoin/bitcoin/pull/32545)
This replaces the cluster linearization algorithm introduced in #30286 (a combination of LIMO with candidate-set search), with a completely different algorithm: ([spanning-forest linearization](https://delvingbitcoin.org/t/spanning-forest-cluster-linearization/1419/1)), which appears to have much better performance for hard clusters. See [this post](https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68) for a comparison between various linearization algorithms, and [this post](https:
...
📝 ant12334 opened a pull request: "Staple"
(https://github.com/bitcoin/bitcoin/pull/32546)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
(https://github.com/bitcoin/bitcoin/pull/32546)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
✅ achow101 closed a pull request: "Staple"
(https://github.com/bitcoin/bitcoin/pull/32546)
(https://github.com/bitcoin/bitcoin/pull/32546)
🤔 tapcrafter reviewed a pull request: "test: properly check for per-tx sigops limit"
(https://github.com/bitcoin/bitcoin/pull/32533#pullrequestreview-2848800587)
tACK 7bc64a8859c3644fdf2eeff59f72a778ae60ea3f
<details>
<summary>Test protocol</summary>
On master (7710a31f0cb69a04529f39840196826d0b9770ab), changing `MAX_STANDARD_TX_SIGOPS_COST` in `src/policy/policy.h` to a higher value didn't cause the tests to fail:
```shell
$ ./build/test/functional/p2p_invalid_tx.py
2025-05-18T07:49:02.383000Z TestFramework (INFO): PRNG seed is: 4606283318320792897
...
2025-05-18T07:49:04.855000Z TestFramework (INFO): Testing invalid transaction: Too
...
(https://github.com/bitcoin/bitcoin/pull/32533#pullrequestreview-2848800587)
tACK 7bc64a8859c3644fdf2eeff59f72a778ae60ea3f
<details>
<summary>Test protocol</summary>
On master (7710a31f0cb69a04529f39840196826d0b9770ab), changing `MAX_STANDARD_TX_SIGOPS_COST` in `src/policy/policy.h` to a higher value didn't cause the tests to fail:
```shell
$ ./build/test/functional/p2p_invalid_tx.py
2025-05-18T07:49:02.383000Z TestFramework (INFO): PRNG seed is: 4606283318320792897
...
2025-05-18T07:49:04.855000Z TestFramework (INFO): Testing invalid transaction: Too
...
💬 katesalazar commented on issue "Option to use dark theme for Windows":
(https://github.com/bitcoin-core/gui/issues/378#issuecomment-2888852325)
> Feel free to open a fresh issue about that.
I won't, busy days.
(https://github.com/bitcoin-core/gui/issues/378#issuecomment-2888852325)
> Feel free to open a fresh issue about that.
I won't, busy days.
💬 romanz commented on pull request "rest: fetch spent transaction outputs by blockhash":
(https://github.com/bitcoin/bitcoin/pull/32540#issuecomment-2888872800)
> Nice.
Thanks :)
> I wonder about just adding a content-type like option so that the api endpoint is the same but you simply say if you want binary or json content returned? Maybe there's other endpoints that it could then be applied to as well.
Good idea - would it be OK to implement it in a separate PR?
(https://github.com/bitcoin/bitcoin/pull/32540#issuecomment-2888872800)
> Nice.
Thanks :)
> I wonder about just adding a content-type like option so that the api endpoint is the same but you simply say if you want binary or json content returned? Maybe there's other endpoints that it could then be applied to as well.
Good idea - would it be OK to implement it in a separate PR?
💬 tapcrafter commented on pull request "node: cap `-maxmempool` and `-dbcache` values for 32-bit":
(https://github.com/bitcoin/bitcoin/pull/32530#discussion_r2094428227)
Do I assume correctly that the reason for this limit not being 4 GiB but only 1 GiB is that the sum of all cache/limit values should be below 4GB to avoid issues on 32-bit systems?
The same question would apply to `MAX_32BIT_MEMPOOL_MB`, what is the rationale for the value of 500MiB?
Not sure if this would fall into the "you chose to shoot yourself in the foot" category, but I wonder: If I turned on all indexes and used the maximum "allowed" values for all of them, would I still be able to r
...
(https://github.com/bitcoin/bitcoin/pull/32530#discussion_r2094428227)
Do I assume correctly that the reason for this limit not being 4 GiB but only 1 GiB is that the sum of all cache/limit values should be below 4GB to avoid issues on 32-bit systems?
The same question would apply to `MAX_32BIT_MEMPOOL_MB`, what is the rationale for the value of 500MiB?
Not sure if this would fall into the "you chose to shoot yourself in the foot" category, but I wonder: If I turned on all indexes and used the maximum "allowed" values for all of them, would I still be able to r
...
🤔 tapcrafter reviewed a pull request: "node: cap `-maxmempool` and `-dbcache` values for 32-bit"
(https://github.com/bitcoin/bitcoin/pull/32530#pullrequestreview-2848812176)
utACK e88056ba323da9127775a41db92835378600d9fc
Will test this later once I've familiarized myself a bit more with the build system to produce 32-bit ARM binaries outside of the guix build.
(https://github.com/bitcoin/bitcoin/pull/32530#pullrequestreview-2848812176)
utACK e88056ba323da9127775a41db92835378600d9fc
Will test this later once I've familiarized myself a bit more with the build system to produce 32-bit ARM binaries outside of the guix build.
💬 tapcrafter commented on pull request "node: cap `-maxmempool` and `-dbcache` values for 32-bit":
(https://github.com/bitcoin/bitcoin/pull/32530#discussion_r2094428985)
I'm a bit surprised there isn't a macro for the 32-bit detection (`sizeof(void*) == 4`). But I'm fairly new to the C++ part of the codebase and I see this is used in other places too, so just a random review thought that can probably be ignored.
(https://github.com/bitcoin/bitcoin/pull/32530#discussion_r2094428985)
I'm a bit surprised there isn't a macro for the 32-bit detection (`sizeof(void*) == 4`). But I'm fairly new to the C++ part of the codebase and I see this is used in other places too, so just a random review thought that can probably be ignored.
📝 luke-jr opened a pull request: "Mining: Avoid copying template CBlocks"
(https://github.com/bitcoin/bitcoin/pull/32547)
Refactoring to avoid unnecessary copies/complexity, at least in the mainnet paths.
Also abstracts out a new `TemplateToJSON` function to keep track of variable scoping better.
(https://github.com/bitcoin/bitcoin/pull/32547)
Refactoring to avoid unnecessary copies/complexity, at least in the mainnet paths.
Also abstracts out a new `TemplateToJSON` function to keep track of variable scoping better.
💬 1440000bytes commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2888896477)
> It seems if you want people to actually use this much OP RETURN data by relaxing the filter it'd make sense to simultaneously prevent "inscriptions" with this #28408
You can ACK this pull request if you agree with the changes and open a new issue or pull request for #28408
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2888896477)
> It seems if you want people to actually use this much OP RETURN data by relaxing the filter it'd make sense to simultaneously prevent "inscriptions" with this #28408
You can ACK this pull request if you agree with the changes and open a new issue or pull request for #28408
⚠️ l3x3l opened an issue: "Unusual "Wallet requires newer version" Error with wallet.dat on macOS, Even with Older Client"
(https://github.com/bitcoin/bitcoin/issues/32548)
### Motivation
I am encountering a persistent "Wallet requires newer version of Bitcoin Core (code -4)" error when trying to open my wallet.dat file on macOS. This issue occurs even when attempting to open the wallet with Bitcoin Core version 0.21.0.1, which the debug log from a later version (29.0) indicated was the last client version to interact with the wallet.
Environment:
* Operating System: macOS (please specify your version if you know it)
* Bitcoin Core Version Initially Used: 29.0
...
(https://github.com/bitcoin/bitcoin/issues/32548)
### Motivation
I am encountering a persistent "Wallet requires newer version of Bitcoin Core (code -4)" error when trying to open my wallet.dat file on macOS. This issue occurs even when attempting to open the wallet with Bitcoin Core version 0.21.0.1, which the debug log from a later version (29.0) indicated was the last client version to interact with the wallet.
Environment:
* Operating System: macOS (please specify your version if you know it)
* Bitcoin Core Version Initially Used: 29.0
...