-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skip most chain sync on startup #2698
Comments
For electrum/esplora clients, to implement this, we probably need to think about switching the order from best_block_updated -> transaction confirmation to transaction confirmation -> best_block_updated. |
Kinda related to lightning/bolts#934 |
That's pretty unrelated - that's just about when our counterparty is stale/has reverted to a previous state. We actually already do that. This is more about us having the latest state, but not the latest blockchain data. |
Sadly I don't think we have the bandwidth in 0.0.119 to dig into this, but hopefully its mostly a documentation thing in a release soon. |
The naive issues with running before we have finished chain sync are not an issue - if we step the channel after the peer has broadcasted the peer has revoked their latest state and we get their money, if we have broadcasted our
ChannelMonitor
should refuse to let us step the channel state machine.There is the issue of if we're way behind and our peer has broadcasted their state, waited the timeout period, then got their funds back. At this point if we step the channel state we potentially lose funds. Still, we could just sync until we reach being behind by the CSV delay on our channels and then sync from there after startup.
May be a bit complicated to do in our sync utils, but we should look into it.
The text was updated successfully, but these errors were encountered: