💬 hebasto commented on pull request "[DO NOT MERGE] cmake: Migrate CI scripts to CMake-based build system -- WIP":
(https://github.com/bitcoin/bitcoin/pull/29790#issuecomment-2147592508)
Rebased. Same as https://github.com/hebasto/bitcoin/pull/220.
(https://github.com/bitcoin/bitcoin/pull/29790#issuecomment-2147592508)
Rebased. Same as https://github.com/hebasto/bitcoin/pull/220.
🚀 fanquake merged a pull request: "fuzz: Make FuzzedSock fuzz friendlier"
(https://github.com/bitcoin/bitcoin/pull/30211)
(https://github.com/bitcoin/bitcoin/pull/30211)
💬 hebasto commented on pull request "ci: add markdown link check job":
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147687209)
After conducting Guix builds, `lint_markdown` starts complaining about docs in `guix-build-*` subdirectories.
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147687209)
After conducting Guix builds, `lint_markdown` starts complaining about docs in `guix-build-*` subdirectories.
💬 willcl-ark commented on pull request "ci: add markdown link check job":
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147694937)
> After conducting Guix builds, `lint_markdown` starts complaining about docs in `guix-build-*` subdirectories.
Oh I didn't consider this directory! I think it should be possible to add `/guix-build-*` to the [ignored files](https://github.com/bitcoin/bitcoin/blob/d39f15a8a5b06d68070a3434a81c6840d4f87715/test/lint/test_runner/src/main.rs#L298).
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147694937)
> After conducting Guix builds, `lint_markdown` starts complaining about docs in `guix-build-*` subdirectories.
Oh I didn't consider this directory! I think it should be possible to add `/guix-build-*` to the [ignored files](https://github.com/bitcoin/bitcoin/blob/d39f15a8a5b06d68070a3434a81c6840d4f87715/test/lint/test_runner/src/main.rs#L298).
💬 hebasto commented on pull request "[27.x] rc2 or final":
(https://github.com/bitcoin/bitcoin/pull/30222#issuecomment-2147698924)
> Backports:
>
> * [build: Fix building `fuzz` binary on on SunOS / illumos #30216](https://github.com/bitcoin/bitcoin/pull/30216)
>
> * [depends: Update Boost download link #30217](https://github.com/bitcoin/bitcoin/pull/30217)
>
>
> I don't think either of these changes warrants an `rc2` cycle.
Agree.
(https://github.com/bitcoin/bitcoin/pull/30222#issuecomment-2147698924)
> Backports:
>
> * [build: Fix building `fuzz` binary on on SunOS / illumos #30216](https://github.com/bitcoin/bitcoin/pull/30216)
>
> * [depends: Update Boost download link #30217](https://github.com/bitcoin/bitcoin/pull/30217)
>
>
> I don't think either of these changes warrants an `rc2` cycle.
Agree.
💬 hebasto commented on pull request "ci: add markdown link check job":
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147702543)
> > After conducting Guix builds, `lint_markdown` starts complaining about docs in `guix-build-*` subdirectories.
>
> Oh I didn't consider this directory! I think it should be possible to add `/guix-build-*` to the [ignored files](https://github.com/bitcoin/bitcoin/blob/d39f15a8a5b06d68070a3434a81c6840d4f87715/test/lint/test_runner/src/main.rs#L298).
This was what I tried before writing my comment :)
It doesn't work, unfortunately.
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147702543)
> > After conducting Guix builds, `lint_markdown` starts complaining about docs in `guix-build-*` subdirectories.
>
> Oh I didn't consider this directory! I think it should be possible to add `/guix-build-*` to the [ignored files](https://github.com/bitcoin/bitcoin/blob/d39f15a8a5b06d68070a3434a81c6840d4f87715/test/lint/test_runner/src/main.rs#L298).
This was what I tried before writing my comment :)
It doesn't work, unfortunately.
💬 willcl-ark commented on pull request "ci: add markdown link check job":
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147704039)
Ah, that is unfortunate. I will try and find another option...
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147704039)
Ah, that is unfortunate. I will try and find another option...
💬 ryanofsky commented on pull request "indexes: Don't wipe indexes again when continuing a prior reindex":
(https://github.com/bitcoin/bitcoin/pull/30132#issuecomment-2147710137)
> Removing the blockman option looks like a nice improvement, but I am not sure yet about the renaming. Going from `do_reindex` to `wipe_block_tree_db` back to `m_reindexing` seems a bit convoluted.
That's a good point. One possible way to address it could be to rename `m_reindexing` as well like 38cc045b6966dda009332695ed55c86bd5a9fea3. If we move away from having multiple variables called "reindex" and instead name variables individually based on what they do, I think it would be an improve
...
(https://github.com/bitcoin/bitcoin/pull/30132#issuecomment-2147710137)
> Removing the blockman option looks like a nice improvement, but I am not sure yet about the renaming. Going from `do_reindex` to `wipe_block_tree_db` back to `m_reindexing` seems a bit convoluted.
That's a good point. One possible way to address it could be to rename `m_reindexing` as well like 38cc045b6966dda009332695ed55c86bd5a9fea3. If we move away from having multiple variables called "reindex" and instead name variables individually based on what they do, I think it would be an improve
...
💬 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.