Improve/simplify node sync for pruned nodes #30224

issue ffrediani openend this issue on June 4, 2024
  1. ffrediani commented at 3:12 pm on June 4, 2024: none

    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 ?

    Related to the incredibly long time that takes to sync the whole blockchain. It also contributes to waste bandwidth for data that will never be kept locally and delays the time for starting using the node that may take a whole week to finish a sync.

    Describe the solution you’d like

    Develop a method for a node when configured to run in pruned mode to only download the necessary data enough to run the pruned node and keep validating new blocks.

    Describe any alternatives you’ve considered

    No response

    Please leave any additional context

    Reopening issue #30220 as a feature request that maflcko arbitrarily closed because he prefer it to be discussed elsewhere he likes better. The issue tracker is the proper and more formal place to discuss possible solutions for an code improvement.

  2. ffrediani added the label Feature on Jun 4, 2024
  3. pinheadmz commented at 3:26 pm on June 4, 2024: member

    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 (reversed) for a chain re-organization.

    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 ?

    It does download the amount of necessary data, which is the entire blockchain. There are other strategies like Assume UTXO which can allow the user to begin using bitcoin while a full sync takes place in the background.

    I agree with the closing of issue #30220 and I am going to close this issue as well. I encourage you to learn more about blockchain pruning and full node operation, and ask further questions like this on https://bitcoin.stackexchange.com

    The Bitcoin Core issue tracker should only be used to report technical problems or feature requests.

    Here are some resources that might help you understand what you are asking about:

    https://bitcoinops.org/en/topics/assumeutxo/

    https://bitcoin.stackexchange.com/questions/59475/blockchain-pruning-and-chainstate

    https://bitcoin.stackexchange.com/questions/92769/bitcoin-full-node-how-to-run-a-pruned-node-explaining-pruning

    https://chat.bitcoinsearch.xyz/?author=holocat&question=Why%2520do%2520pruned%2520nodes%2520need%2520to%2520download%2520the%2520entire%2520blockchain%253F

  4. pinheadmz closed this on Jun 4, 2024

  5. ffrediani commented at 4:28 pm on June 4, 2024: none

    @pinheadmz if there are alternatives ways and strategies why just stay with what is there right now and not improve it for these scenarios ?

    Seems some developers in this project don’t like to have issues opened they can’t or are unwilling to work on and arbitrarily close them. I still disagree with this autocratic behaviour and that it should be discussed elsewhere. Seems more a personal preference of some rather than how it really is.

    This is a feature request and as such has a place in here, otherwise it wouldn’t be an option when opening an issue. Why to close a Feature Request opened in the proper place ?


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-21 15:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me