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

[cdecker]

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

• [ ] Load and store the bitcoind headers count in the chain_topology
• [ ] Allow waitblockheight to wait on the headers from bitcoind instead
• [ ] Base the CLTV values in libplugin-pay.c on the header count instead
• [ ] Use in == NULL / am_origin to identify payments originating locally
• [ ] Allow locally originating payments to bypass the sync check

[ZmnSCPxj]

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]

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.