ElementsProject / lightning

Core Lightning — Lightning Network implementation focusing on spec compliance and performance
Other
2.84k stars 901 forks source link

feature: Allow sending HTLCs even if not fully synced with the blockchain #4979

Open cdecker opened 2 years ago

cdecker commented 2 years ago

Currently we require a node to be fully synced with the blockchain before allowing HTLCs to be sent. This is suboptimal in cases in which the node is started briefly, some operations are performed (such as calling pay) and then preempted after a while. The user expects the operations to work, however they fail due to HTLCs requiring being up to date.

The code in question is here:

https://github.com/ElementsProject/lightning/blob/5bbe3feee77b039cdb83c11420d36edbd4c5cc26/lightningd/peer_htlcs.c#L668-L672

This was likely chosen because the HTLC timelock is compared against our current sync height, and we fail the HTLC with a different error if the timelock is too far in the future. It'd be better to base those decisions on the header count in bitcoind rather than our own internal height for HTLCs originating locally.

Applying this only to local HTLCs is important since for forwarding payments we may get tricked into receiving a forwarding from a channel that is closed on-chain, but we're not aware of it yet. This is not an issue with locally originating payments since the trigger is the local node itself, and if it works we have the desired effect, if it doesn't (because the channel was inadvertently closed) we're still getting the current behavior.

Todo

ZmnSCPxj commented 2 years ago

Allow waitblockheight to wait on the headers from bitcoind instead

Maybe this should be a different API? waitblockheight ensures that lightningd knows the blocks and transactions up to that height, which might be significant to some plugin somewhere...? Maybe?

cdecker commented 2 years ago

Yeah, that's pretty much the idea here: make waitblockheight a bit more flexible by being able to specify whether we want ourselves to be at least at that height (blocks processed by lightningd) or we want the network to be at that height (headers processed by bitcoind). Very much just two different aspects of the same thing really.