Improve/simplify node sync for pruned nodes #30220

issue ffrediani openend this issue on June 3, 2024
  1. ffrediani commented at 4:25 pm on June 3, 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

    No response

  2. ffrediani added the label Feature on Jun 3, 2024
  3. maflcko commented at 8:56 am on June 4, 2024: member

    This is possible to implement, but may be controversial, depending on how it is implemented. You can learn more about the topic by reading the various discussions around assumeutxo.

    Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base.

    General bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange or the #bitcoin IRC channel on Libera Chat, or one of the Bitcoin subreddits, or any other place that you feel is well suited.

  4. maflcko closed this on Jun 4, 2024

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

    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 their own nodes much easier and quicker (not having to wait for the entire and perhaps unnecessary sync) and contribute further to the network.

    These other tools are not for requests, but more informal tools to discuss stuff freely where information can easily get lost and not always captured properly. The issue tracker allows the directly involved people to discuss and find out the proper solution to an existing issue.

  6. ffrediani commented at 3:06 pm on June 4, 2024: none
    @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.
  7. maflcko commented at 3:37 pm on June 4, 2024: member
    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.
  8. ffrediani commented at 4:23 pm on June 4, 2024: none
    I wish to contribute this way, having a proper and structured discussion about a topic which is still an issue. If you want to suggest other ways to contribute it is fine, but I hope you are not making it a must on the way I must contribute. Creating this issue contributes to raise awareness to the issue (which currently exists), to discuss possible solution and have a solution implemented for it.
  9. maflcko commented at 4:28 pm on June 4, 2024: member
    Can you explain how your discussion is different from the assumeutxo discussions already happening? I don’t think it makes sense to have duplicate and redundant issues.

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