Implement on-the-fly funding based on splicing and liquidity ads by t-bast · Pull Request #2861 · ACINQ/eclair

t-bast · 2024-06-07T12:48:06Z

Implement the on-the-fly funding protocol specified in lightning/blips#36: when a payment cannot be relayed because of a liquidity issue, we notify our peer that we'd like to trigger on-the-fly funding if available. If available, we send a funding proposal (will_add_htlc) and keep track of its status.

Once a matching funding transaction is signed, we persist this funding attempt and wait for the additional liquidity to be available (once the channel is ready or the splice locked). We will then frequently try to relay the payment to get paid our liquidity fees. If the payment keeps getting rejected, or we cannot connect to our peer, we abandon the
payment when it reaches its CLTV expiry, which ensures that the upstream channels are not at risk.

When using on-the-fly funding, we use a single channel with our peer. If they try to open another channel while one is available, we reject their request and expect a splice instead.

This is best reviewed commit-by-commit: the bulk of the implementation is in the last commit, which contains some subtleties to correctly handle all edge cases (covered by the various unit tests).

Add the (disabled by default) `on_the_fly_funding` feature bit and codecs for the corresponding messages: - `will_add_htlc` - `will_fail_htlc` - `will_fail_malformed_htlc` - `cancel_on_the_fly_funding` We also add a TLV to `update_add_htlc` to notify the recipient that we relayed less data than what the onion encodes, in exchange for the fees of the specified funding transaction.

We add a non-standard channel flag to `open_channel2` to allow wallets to ask their peer to pay the commit tx fees, even when they're not the channel opener. This is necessary for on-the-fly funding, until we can move to 0-fee commit txs which will make it obsolete.

When an interactive-tx session is created for a liquidity purchase that uses future HTLCs to pay fees, the initiator may not have enough funds to honor the target feerate. We allow the transaction anyway, because we want to get paid for the liquidity we're providing. If the feerate is too low and the transaction doesn't confirm, we can double-spend it if we need that liquidity elsewhere.

This commit adds the funding fee field to HTLCs, but never sets it. We update a lot of test files, but there is no functional change.

Implement the on-the-fly funding protocol: when a payment cannot be relayed because of a liquidity issue, we notify the `Peer` actor that we'd like to trigger on-the-fly funding if available. If available, we we send a funding proposal to our peer and keep track of its status. Once a matching funding transaction is signed, we persist this funding attempt and wait for the additional liquidity to be available (once the channel is ready or the splice locked). We will then frequently try to relay the payment to get paid our liquidity fees. If the payment keeps getting rejected, or we cannot connect to our peer, we abandon the payment when it reaches its CLTV expiry, which ensures that the upstream channels are not at risk. When using on-the-fly funding, we use a single channel with our peer. If they try to open another channel while one is available, we reject their request and expect a splice instead.

Similar to #2461 but for the non-initiator of a channel open.

We check the remote features before initiating an on-the-fly funding attempt: it doesn't make sense to initiate it if our peer has not activated the feature.

Instead of handling command responses and settlement in parallel (which is a bit confusing), we stash settlements, process all command responses, and then preocess all settlements. This makes the flow a bit more strict (as modifications to tests show), but it's easier to follow what the fsm does.

…ds (#2861)

t-bast · 2024-06-07T12:48:06Z