Implement on-the-fly funding based on splicing and liquidity ads #2861
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
t-bast
force-pushed
the
on-the-fly-funding
branch
4 times, most recently
from
789eef8 to
9d8eb99
Compare
t-bast
force-pushed
the
on-the-fly-funding
branch
5 times, most recently
from
16a5191 to
b340247
Compare
t-bast
force-pushed
the
on-the-fly-funding
branch
4 times, most recently
from
55558aa to
ce1d166
Compare
t-bast
force-pushed
the
on-the-fly-funding
branch
from
ce1d166 to
64e447f
Compare
t-bast
force-pushed
the
on-the-fly-funding
branch
2 times, most recently
from
e704f28 to
b95e3a1
Compare
t-bast
force-pushed
the
on-the-fly-funding
branch
2 times, most recently
from
231f450 to
7dd2086
Compare
t-bast
force-pushed
the
on-the-fly-funding
branch
from
7dd2086 to
4312da7
Compare
t-bast
force-pushed
the
on-the-fly-funding
branch
from
4312da7 to
881bd40
Compare
t-bast
force-pushed
the
on-the-fly-funding
branch
from
881bd40 to
6d35c43
Compare
t-bast
force-pushed
the
on-the-fly-funding
branch
from
6d35c43 to
81ef78f
Compare
t-bast
commented
Aug 28, 2024
eclair-core/src/test/scala/fr/acinq/eclair/payment/relay/NodeRelayerSpec.scala
Show resolved
Hide resolved
t-bast
force-pushed
the
on-the-fly-funding
branch
5 times, most recently
from
f2973ad to
9f1ace1
Compare
t-bast
force-pushed
the
on-the-fly-funding
branch
5 times, most recently
from
3f0c56d to
69014d2
Compare
pm47
reviewed
Sep 19, 2024
pm47
reviewed
Sep 23, 2024
eclair-core/src/main/scala/fr/acinq/eclair/payment/relay/NodeRelay.scala
Outdated
Show resolved
Hide resolved
pm47
reviewed
Sep 23, 2024
eclair-core/src/main/scala/fr/acinq/eclair/payment/relay/NodeRelay.scala
Outdated
Show resolved
Hide resolved
t-bast
force-pushed
the
on-the-fly-funding
branch
from
0c62d8d to
1e0bbe9
Compare
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.
t-bast
force-pushed
the
on-the-fly-funding
branch
from
1e0bbe9 to
7e740e6
Compare
pm47
reviewed
Sep 24, 2024
eclair-core/src/main/scala/fr/acinq/eclair/payment/relay/OnTheFlyFunding.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/payment/relay/OnTheFlyFunding.scala
Outdated
Show resolved
Hide resolved
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.
pm47
approved these changes
Sep 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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).