Syncing takes many days with state of the art hardware now - Reviving bootstrapping as a solution? #34121

1. 
   viaj3ro commented at 5:39 pm on December 19, 2025: none

   Please describe the feature you’d like to see added.

   I run the lightning node SilentBob and recently nuked my Bitcoin chainstate or blocks database while trying to fix my issues with running out of disc space.

   Resyncing turned out to take many days, even on modern hardware. In fact, I’m still waiting two days later with the estimated time remaining constantly switching between many hours, many days or even many weeks at times (13th gen i7 10 core CPU, super fast NVME 2TB SSD, 16 gig ram, 12 gig reserved for bitcoin… 500 Mbit cable connection).

   Luckily @C-Otto saved me by providing me with his blocks and chainstate directories and he mentioned that he might be able to provide the same service to others if there is any demand.

   So I thought I should bring this up here and inquire if there is any interest in reviving bootstrapping again, as it has existed until 2014: https://bitcoin.org/bin/block-chain/README.txt

2. viaj3ro added the label Feature on Dec 19, 2025
3. 
   l0rinc commented at 6:02 pm on December 19, 2025: contributor

   Resyncing turned out to take many days

   Do I understand you correctly that this was a full Initial Block Download (i.e. no prior state locally) or was it a -reindex or -reindex-chainstate?

   12 gig reserved for bitcoin

   Can you please share the exact configs you have started the node with? Using a dbcache that large can sometimes result in memory swapping which dramatically slows down execution. We found that there’s rarely a need to go beyond 3GB dbcache.

   500 Mbit cable connection

   That should suffice, but if it’s over TOR, it can often take days.

   Lastly, which Core version were you using? Older ones have a low assumevalid which forces script (re)validation which can slow down simple devices a lot. Core v30 can do IBD 200% faster than e.g. v25 - make sure you use the latest.

   Also, we’re working on parallelizing part of the validation work (block input fetching for example), it should result in another 30-50% speedup, see: #31132. Even on simple Umbrel and Raspberry 5 devices we’re getting validation speeds of 7-10 hours with that.

4. 
   viaj3ro commented at 6:09 pm on December 19, 2025: none

   Initially I tried to just do -reindex on the nodes itself. While setting up a fresh installation on the above mentioned machine as a backup plan. The reindex was so painfully slow (much slower than starting from scratch on the soewhat faster machine) that I gave up on it.

   config: server=1 txindex=1 dbcache=12048

   It never came even close to using 8 gig of RAM anyway.

   clearnet, not TOR. Syncing until 2020 was reasonably fast. slowed down a lot until 2024 and its a crawl since then

5. 
   sipa commented at 6:09 pm on December 19, 2025: member

   So I thought I should bring this up here and inquire if there is any interest in reviving bootstrapping again, as it has existed until 2014: https://bitcoin.org/bin/block-chain/README.txt

   It won’t help you. If synchronization takes days, it’s not the downloading that’s the bottleneck, but validation. Validating a bootstrap.dat would take just as long. (Unless of course your network connection somehow is that slow, but in that case downloading the bootstrap.dat file will just be as long)

   The bootstrap.dat approach was abandoned because it’s generally faster to just sync from the network since Bitcoin Core 0.12, as it downloads and validates in parallel. If you use bootstrap.dat, you need to first download the whole file, and only then validate it.

6. 
   viaj3ro commented at 6:13 pm on December 19, 2025: none

   Downloading blocks and chainstate took around 7 hours. The node was starting right away. No need for revalidating.

   It only took another 4h because eclair requires txindex=1 (which @C-Otto doesn’t need since he runs LND)

   so boostrapping saved me at least 2 days at this point already. potentially many more

7. 
   C-Otto commented at 6:14 pm on December 19, 2025: none

   To clarify: I provided the blocks/ and chainstate/ directories. I believe that a non-validating approach (like this) isn’t in the best interest of the project.
8. 
   viaj3ro commented at 6:15 pm on December 19, 2025: none

   wouldn’t it be possible to provide it verifiably via checksum / hash?
9. 
   sipa commented at 6:17 pm on December 19, 2025: member

   If you’re copying the chainstate directory from someone else, you’re not validating history. That will obviously be faster, but isn’t comparable to the bootstrap.dat method (which still validated the whole history on import).

   wouldn’t it be possible to provide it verifiably via checksum / hash?

   Yes, of course, if you somehow get the checksum from a trusted source. There is ongoing work in the Bitcoin Core project to enable that through the assumeutxo project, but it’s a very different security tradeoff.

10. 
    l0rinc commented at 6:18 pm on December 19, 2025: contributor

    Can you please try a -reindex-chainstate with -dbcache=3000 instead? It would be useful for us to know why it’s so slow for some people…
11. 
    viaj3ro commented at 6:23 pm on December 19, 2025: none

    Can you please try a -reindex-chainstate with -dbcache=3000 instead? It would be useful for us to know why it’s so slow for some people…

    can do, once the fresh bitcoin installation is fully synced. I can’t play around with bitcoin on my active lightning node unfortunately. I’m almost certain the large dbcache wasn’t causing issues. I was monitoring RAM usage and it never came close to using all

    The new sync stands at 53 hours currently (may 2025) with an estimated 10 hours to 3 days still to go

12. 
    andrewtoth commented at 7:01 pm on December 21, 2025: contributor

    I recently benchmarked #31132 with network connected storage and it likely solves this problem #31132 (comment). The issue is that fetching inputs single threaded with high latency but high throughput storage is unable to utilize any of the throughput.

    Please review or test.

13. 
    Sjors commented at 3:59 am on December 30, 2025: member

    @viaj3ro you could also try the AssumeUTXO feature (loadtxoutset), https://github.com/bitcoin-core/bitcoincore.org/pull/1197 links to a torrent for the most recent snapshot. It doesn’t reduce total sync time, but once it’s synced to the tip your lightning node should work.

Contributors
viaj3ro l0rinc sipa C-Otto andrewtoth Sjors

Labels
Feature