Skip to content

Conversation

@JoseSK999
Copy link
Member

@JoseSK999 JoseSK999 commented Feb 9, 2026

Description and Notes

This PR depends on #836

I've changed the catch_up context so that your florestad starts with SwiftSync. It will also request legacy blocks, so this runs witnessless, but just for testing purposes. A future PR should actually implement the witnessless version.

Now, once your florestad starts, it will try to read the hints file from the same datadir as your node uses. Default directory is .floresta in the root for mainnet (and .floresta/signet, etc.). So you need to have the hints file there, named signet.hints or testnet.hints or bitcoin.hints.

I got mine from the server hosted by 2140-dev:

curl -o signet.hints http://utxohints.store/hints/signet

NOTE: to run florestad on mainnet you need to pass -- --no-assume-utreexo.

So you paste the hints file in the datadir, and then florestad will be able to run SwifSync. Four things can happen:

  • SwiftSync finishes correctly ✅
  • SwiftSync hints are invalid as the final agg is not zero ‼️
  • An invalid block is found (below SwiftSync stop height) 😢
  • We finish SwiftSync but the supply is invalid 💀

In the last three cases we abort SwiftSync and switch to SyncNode. There is an integration test showing how we would react against an invalid block.

If you finish SwiftSync you better stop the node because our acc is Stump::new() and you reject blocks/proofs (TODO allow SwiftSync to build the accumulator). ALSO to run this a couple of times you will need to remove the chaindata folder, so that it starts from 0 again.

This should be >10x faster than SyncNode for IBD as we avoid the utreexo proof bottleneck. In my case it was ~12x faster.

@Davidson-Souza
Copy link
Member

curl -o signet.hints http://utxohints.store/hints/signet

HTTPS*. HTTP will return a 301

@luisschwab luisschwab self-requested a review February 9, 2026 12:57
@Davidson-Souza Davidson-Souza added enhancement New feature or request performance This is a performance-related issue labels Feb 9, 2026
@JoseSK999
Copy link
Member Author

Fixed an error with out inflight requests: we must not drop any of them before completion, even if redo_inflight_request fails. If redoing fails, we insert again the request (it will be retried later with another peer).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request performance This is a performance-related issue

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants