💬 instagibbs commented on pull request "util: add BitSet":
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626157391)
I like the comment in the VecDeque PR better if you'd care to just copy it here: https://github.com/bitcoin/bitcoin/pull/30161/commits/ecb278bb19c53b007380e262fa86d809255eeb49#diff-1f28310f089eac74210ecbc0db2083279282ade962dc464bd31448480dc5563dR59
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626157391)
I like the comment in the VecDeque PR better if you'd care to just copy it here: https://github.com/bitcoin/bitcoin/pull/30161/commits/ecb278bb19c53b007380e262fa86d809255eeb49#diff-1f28310f089eac74210ecbc0db2083279282ade962dc464bd31448480dc5563dR59
💬 hebasto commented on pull request "util: add BitSet":
(https://github.com/bitcoin/bitcoin/pull/30160#issuecomment-2147744433)
Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/30160#issuecomment-2147744433)
Concept ACK.
💬 ffrediani commented on issue "Improve/simplify node sync for pruned nodes":
(https://github.com/bitcoin/bitcoin/issues/30220#issuecomment-2147764437)
Thanks @maflcko
The point perhaps it to find the proper way to implement this that doesn't cause trouble to these scenarios where a pruned node can be used and older stuff may almost never need to be accessed, and if so can be fetched as necessary.
I consider this is an issue given the very long time it takes to sync the whole blockchain, the amount of bandwidth wasted for something that could be simplified and improved greatly. This can also contribute to more adoption for people to run the
...
(https://github.com/bitcoin/bitcoin/issues/30220#issuecomment-2147764437)
Thanks @maflcko
The point perhaps it to find the proper way to implement this that doesn't cause trouble to these scenarios where a pruned node can be used and older stuff may almost never need to be accessed, and if so can be fetched as necessary.
I consider this is an issue given the very long time it takes to sync the whole blockchain, the amount of bandwidth wasted for something that could be simplified and improved greatly. This can also contribute to more adoption for people to run the
...
💬 ffrediani commented on issue "Improve/simplify node sync for pruned nodes":
(https://github.com/bitcoin/bitcoin/issues/30220#issuecomment-2147773585)
@maflcko please don't just close the issue because you think that should be discussed elsewhere you prefer and may not be interested in developing it. If this can be developed and there is a solution for it then that is the right place to be.
(https://github.com/bitcoin/bitcoin/issues/30220#issuecomment-2147773585)
@maflcko please don't just close the issue because you think that should be discussed elsewhere you prefer and may not be interested in developing it. If this can be developed and there is a solution for it then that is the right place to be.
⚠️ ffrediani opened an issue: "Improve/simplify node sync for pruned nodes"
(https://github.com/bitcoin/bitcoin/issues/30224)
### Please describe the feature you'd like to see added.
When running a pruned node it means it will keep only last X amount of GB predefined in the configuration, so why is it necessary to download the whole blockchain if only a tiny part will be kept at the end ? Can't it just download the amount of necessary and most recent data or a method developed for it and to speed up adoption of pruned nodes that will never keep all that amount of data ?
### Is your feature related to a problem, if so
...
(https://github.com/bitcoin/bitcoin/issues/30224)
### Please describe the feature you'd like to see added.
When running a pruned node it means it will keep only last X amount of GB predefined in the configuration, so why is it necessary to download the whole blockchain if only a tiny part will be kept at the end ? Can't it just download the amount of necessary and most recent data or a method developed for it and to speed up adoption of pruned nodes that will never keep all that amount of data ?
### Is your feature related to a problem, if so
...
💬 ismaelsadeeq commented on pull request "test: MiniWallet: respect passed feerate for padded txs (using `target_weight`)":
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1626111198)
nit:
```suggestion
dummy_vbytes = (target_weight - tx.get_weight() + 3) // WITNESS_SCALE_FACTOR
```
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1626111198)
nit:
```suggestion
dummy_vbytes = (target_weight - tx.get_weight() + 3) // WITNESS_SCALE_FACTOR
```
💬 ismaelsadeeq commented on pull request "test: MiniWallet: respect passed feerate for padded txs (using `target_weight`)":
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1626172127)
In case of failure these lines wont be reached as we will fail early in `_bulk_tx`.
I think delegating the weight verification to `__bulk_tx` is more elegant, else It will be messy for all `create_self_transfer` callers to verify the tx weight and the target weight.
It will be cleaner to just delete this and move the debugging to `__bulk_tx`.
```suggestion
```
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1626172127)
In case of failure these lines wont be reached as we will fail early in `_bulk_tx`.
I think delegating the weight verification to `__bulk_tx` is more elegant, else It will be messy for all `create_self_transfer` callers to verify the tx weight and the target weight.
It will be cleaner to just delete this and move the debugging to `__bulk_tx`.
```suggestion
```
✅ pinheadmz closed an issue: "Improve/simplify node sync for pruned nodes"
(https://github.com/bitcoin/bitcoin/issues/30224)
(https://github.com/bitcoin/bitcoin/issues/30224)
💬 pinheadmz commented on issue "Improve/simplify node sync for pruned nodes":
(https://github.com/bitcoin/bitcoin/issues/30224#issuecomment-2147819544)
> When running a pruned node it means it will keep only last X amount of GB predefined in the configuration, so why is it necessary to download the whole blockchain if only a tiny part will be kept at the end ?
Because a fully validating node must have the entire UTXO set to continue validate new blocks, and that UTXO set can only be computed by processing the entire blockchain. The "tiny part" of block data the prune node does keep on disk is only there in case the blockchain is rewound (rev
...
(https://github.com/bitcoin/bitcoin/issues/30224#issuecomment-2147819544)
> When running a pruned node it means it will keep only last X amount of GB predefined in the configuration, so why is it necessary to download the whole blockchain if only a tiny part will be kept at the end ?
Because a fully validating node must have the entire UTXO set to continue validate new blocks, and that UTXO set can only be computed by processing the entire blockchain. The "tiny part" of block data the prune node does keep on disk is only there in case the blockchain is rewound (rev
...
👍 ismaelsadeeq approved a pull request: "test: MiniWallet: respect passed feerate for padded txs (using `target_weight`)"
(https://github.com/bitcoin/bitcoin/pull/30162#pullrequestreview-2096759851)
Code Review ACK 39d135e79f3f0c40dfd8fad2c53723d533cd19b4 🚀
I've tested this locally
c17550bc3a6 ensures that the target weight is calculated correctly, at most we get 3 off.
b2f0a9f8b07 fails without the first commit.
c17550bc3a6 fixes the issue of respecting fee rate when target weight is provided, as large tx now has correct fee rate.
My comments are not blockers, just suggestions for improvement, can come in a follow-up, but happy to reACK when fixed.
(https://github.com/bitcoin/bitcoin/pull/30162#pullrequestreview-2096759851)
Code Review ACK 39d135e79f3f0c40dfd8fad2c53723d533cd19b4 🚀
I've tested this locally
c17550bc3a6 ensures that the target weight is calculated correctly, at most we get 3 off.
b2f0a9f8b07 fails without the first commit.
c17550bc3a6 fixes the issue of respecting fee rate when target weight is provided, as large tx now has correct fee rate.
My comments are not blockers, just suggestions for improvement, can come in a follow-up, but happy to reACK when fixed.
💬 ryanofsky commented on pull request "wallet: Ensure best block matches wallet scan state":
(https://github.com/bitcoin/bitcoin/pull/30221#issuecomment-2147839858)
I'm not sure, but it seems like a potentially good thing to me that `last_block_processed` and BESTBLOCK are two distinct concepts.
The last block processed is the block that CWallet in-memory state has been synced to (particularly CWalletTx::m_state which includes mempool / abandoned information not serialized to disk).
The BESTBLOCK record is the last block whose data has been flushed to disk, that the wallet should begin syncing from next time it is reloaded.
It seems like the first
...
(https://github.com/bitcoin/bitcoin/pull/30221#issuecomment-2147839858)
I'm not sure, but it seems like a potentially good thing to me that `last_block_processed` and BESTBLOCK are two distinct concepts.
The last block processed is the block that CWallet in-memory state has been synced to (particularly CWalletTx::m_state which includes mempool / abandoned information not serialized to disk).
The BESTBLOCK record is the last block whose data has been flushed to disk, that the wallet should begin syncing from next time it is reloaded.
It seems like the first
...
💬 maflcko commented on issue "Improve/simplify node sync for pruned nodes":
(https://github.com/bitcoin/bitcoin/issues/30220#issuecomment-2147845035)
If you want to help bring assumeutxo forward, you can help reviewing the outstanding pull requests. A lot of work has already been done, some work remains, but creating this issue will not help bring it forward. If you want to contribute otherwise to assumeutxo, you can read the previous discussions and contribute to them, if there is anything that has been missed.
(https://github.com/bitcoin/bitcoin/issues/30220#issuecomment-2147845035)
If you want to help bring assumeutxo forward, you can help reviewing the outstanding pull requests. A lot of work has already been done, some work remains, but creating this issue will not help bring it forward. If you want to contribute otherwise to assumeutxo, you can read the previous discussions and contribute to them, if there is anything that has been missed.
💬 achow101 commented on pull request "wallet: Ensure best block matches wallet scan state":
(https://github.com/bitcoin/bitcoin/pull/30221#issuecomment-2147869048)
> The last block processed is the block that CWallet in-memory state has been synced to (particularly CWalletTx::m_state which includes mempool / abandoned information not serialized to disk).
But none of that state is relevant to the last block processed. Any state related to blocks (confirmed or conflicted) is written to disk.
> The BESTBLOCK record is the last block whose data has been flushed to disk, that the wallet should begin syncing from next time it is reloaded.
The point is t
...
(https://github.com/bitcoin/bitcoin/pull/30221#issuecomment-2147869048)
> The last block processed is the block that CWallet in-memory state has been synced to (particularly CWalletTx::m_state which includes mempool / abandoned information not serialized to disk).
But none of that state is relevant to the last block processed. Any state related to blocks (confirmed or conflicted) is written to disk.
> The BESTBLOCK record is the last block whose data has been flushed to disk, that the wallet should begin syncing from next time it is reloaded.
The point is t
...
💬 ryanofsky commented on pull request "wallet: Avoid potentially writing incorrect best block locator":
(https://github.com/bitcoin/bitcoin/pull/29652#issuecomment-2147877812)
> I'm now wondering whether the wallet should even be doing anything on ChainStateFlushed since that doesn't seem like it should have any bearing on what the wallet knows about.
Notifications are sent in order, so it does have some meaning. It means wallet is in-between blockConnected events and synchronized up to some block, and that the node has written some data to disk recently, so the wallet may want write its data to disk, too.
I think the only problem with the ChainStateFlushed noti
...
(https://github.com/bitcoin/bitcoin/pull/29652#issuecomment-2147877812)
> I'm now wondering whether the wallet should even be doing anything on ChainStateFlushed since that doesn't seem like it should have any bearing on what the wallet knows about.
Notifications are sent in order, so it does have some meaning. It means wallet is in-between blockConnected events and synchronized up to some block, and that the node has written some data to disk recently, so the wallet may want write its data to disk, too.
I think the only problem with the ChainStateFlushed noti
...
💬 ryanofsky commented on pull request "wallet: Ensure best block matches wallet scan state":
(https://github.com/bitcoin/bitcoin/pull/30221#issuecomment-2147885391)
> It doesn't make sense to me that we wouldn't store the block the wallet's state has been synced to
You may be right this is the better approach. But I think the previous approach does make some sense, too. You might not want to write to the wallet database each time a block is connected if the block doesn't contain any relevant transactions, especially during reindexing.
(https://github.com/bitcoin/bitcoin/pull/30221#issuecomment-2147885391)
> It doesn't make sense to me that we wouldn't store the block the wallet's state has been synced to
You may be right this is the better approach. But I think the previous approach does make some sense, too. You might not want to write to the wallet database each time a block is connected if the block doesn't contain any relevant transactions, especially during reindexing.
💬 sipa commented on pull request "util: add BitSet":
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626264025)
Done, let me know if this is better.
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626264025)
Done, let me know if this is better.
💬 sipa commented on pull request "util: add BitSet":
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626264244)
Added.
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626264244)
Added.
💬 sipa commented on pull request "util: add BitSet":
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626264403)
Done.
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626264403)
Done.
💬 sipa commented on pull request "util: add BitSet":
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626265719)
Yes; but on GCC/stdlibc++, `std::popcount` just uses `__builtin_popcount`, which in benchmarks seems to perform worse than the code here. The I've updated the comment to reflect that (it was written before the C++20 switch which introduced `std::popcount`).
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626265719)
Yes; but on GCC/stdlibc++, `std::popcount` just uses `__builtin_popcount`, which in benchmarks seems to perform worse than the code here. The I've updated the comment to reflect that (it was written before the C++20 switch which introduced `std::popcount`).
💬 sipa commented on pull request "util: add BitSet":
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626266141)
Done. Credit to @glozow.
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626266141)
Done. Credit to @glozow.