8000 Implement on-the-fly funding based on splicing and liquidity ads by t-bast · Pull Request #2861 · ACINQ/eclair · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Implement on-the-fly funding based on splicing and liquidity ads #2861

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 9 commits into from
Sep 25, 2024
Merged

Implement on-the-fly funding based on splicing and liquidity ads #2861

merged 9 commits into from
Sep 25, 2024

Conversation

t-bast
Copy link
Member
@t-bast t-bast commented Jun 7, 2024 •
edited
Loading

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).

@t-bast t-bast force-pushed the on-the-fly-funding branch 4 times, most recently from 789eef8 to 9d8eb99 Compare June 14, 2024 11:26
@t-bast t-bast force-pushed the on-the-fly-funding branch 5 times, most recently from 16a5191 to b340247 Compare June 25, 2024 07:00
@t-bast t-bast force-pushed the on-the-fly-funding branch 4 times, most recently from 55558aa to ce1d166 Compare July 2, 2024 08:29
@t-bast t-bast mentioned this pull request Jul 2, 2024
Open
@t-bast t-bast force-pushed the on-the-fly-funding branch from ce1d166 to 64e447f Compare July 2, 2024 16:07
@pm47 pm47 self-requested a review July 4, 2024 14:06
@t-bast t-bast mentioned this pull request Jul 4, 2024
Merged
@t-bast t-bast force-pushed the on-the-fly-funding branch 2 times, most recently from e704f28 to b95e3a1 Compare July 8, 2024 09:56
@t-bast t-bast marked this pull request as ready for review July 8, 2024 14:57
@t-bast t-bast force-pushed the on-the-fly-funding branch 2 times, most recently from 231f450 to 7dd2086 Compare July 9, 2024 10:10
@t-bast t-bast mentioned this pull request Jul 9, 2024
Merged
@t-bast t-bast force-pushed the on-the-fly-funding branch from 7dd2086 to 4312da7 Compare July 9, 2024 15:04
@t-bast t-bast force-pushed the on-the-fly-funding branch from 4312da7 to 881bd40 Compare July 17, 2024 13:37
@t-bast t-bast mentioned this pull request Jul 18, 2024
Merged
@t-bast t-bast force-pushed the on-the-fly-funding branch from 881bd40 to 6d35c43 Compare July 22, 2024 09:21
@t-bast t-bast force-pushed the on-the-fly-funding branch from 6d35c43 to 81ef78f Compare August 1, 2024 07:55
@t-bast t-bast mentioned this pull request Aug 7, 2024
Closed
@t-bast t-bast force-pushed the on-the-fly-funding branch 5 times, most recently from f2973ad to 9f1ace1 Compare September 9, 2024 10:08
@t-bast t-bast force-pushed the on-the-fly-funding branch 5 times, most recently from 3f0c56d to 69014d2 Compare September 16, 2024 11:55
pm47
pm47 reviewed Sep 19, 2024
View reviewed changes
@t-bast
Add on_the_fly_funding feature bit and messages
e894d8a 
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.
@t-bast
Add non_initiator_pays_commit_fees channel flag
e2e21a4 
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.
@t-bast
Allow underpaying feerate when using future HTLCs
cddf848 
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.
@t-bast
Add funding_fee field to CMD_ADD_HTLC
fa2bf42 
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.
@t-bast
Implement on-the-fly funding
a4a7264 
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.
@t-bast
Add requireConfirmedInputs to non-initiator init
2fe9265 
Similar to #2461 but for the non-initiator of a channel open.
@t-bast
Don't initiate on-the-fly-funding if remote feature not active
4c4d486 
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
Improve logs and maximum payment attempts
7e740e6
pm47
pm47 reviewed Sep 24, 2024
View reviewed changes
@t-bast
Process CommandResponse first, settlement next
8938451 
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.
@t-bast t-bast merged commit de42c8a into master Sep 25, 2024
1 check passed
@t-bast t-bast deleted the on-the-fly-funding branch September 25, 2024 11:01
pm47 added a commit that referenced this pull request Sep 26, 2024
@pm47
fixup! Implement on-the-fly funding based on splicing and liquidity a…
bbf4cd0 
…ds (#2861)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pm47 pm47 pm47 approved these changes

Assignees
No one assigned
Labels
Optech Make Me Famous!
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@t-bast @pm47
0