Skip to content
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

On-the-fly channel funding based on splicing and liquidity ads #649

Merged
merged 8 commits into from
Sep 25, 2024
Merged

On-the-fly channel funding based on splicing and liquidity ads #649

merged 8 commits into from
Sep 25, 2024

Commits on Sep 18, 2024

  1. Remove please_open_channel 

    It is usually the wallet that decides that it needs a channel, but we
want the LSP to pay the commit fees to allow the wallet user to empty
its wallet over lightning. We previously used a `please_open_channel`
message that was sent by the wallet to the LSP, but it doesn't work
well with liquidity ads.

We remove that message and instead send `open_channel` from the wallet
but with a custom channel flag that tells the LSP that they should be
paying the commit fees. This only works if the LSP adds funds on their
side of the channel, so we couple that with liquidity ads to request
funds from the LSP.

We also add a `recommended_feerates` message from the LSP which lets
the wallet know the on-chain feerates that the LSP will accept for
on-chain funding operations, since those feerates are set in the
`open_channel` message that is now sent by the wallet.
    @t-bast
    t-bast committed Sep 18, 2024
    Configuration menu
    Copy the full SHA
    8a4e6ff View commit details
    Browse the repository at this point in the history

  2. Add liquidity ads to the channel opening flow 

    We previously only used liquidity ads with splicing: we now support it
during the initial channel opening flow as well. This lets us add more
unit tests, including tests for the case where the node receiving the
`open_channel` message is responsible for paying the commitment fees.

We also update liquidity ads to use the latest version of the spec from
lightning/bolts#1153. This introduces more ways
of paying the liquidity fees, to support on-the-fly funding without
existing channel balance (not implemented in this commit).

Note that we need some backwards-compatibility with the previous
liquidity ads types in our state serialization code: when we're in the
middle of signing a splice transaction, we may have a legacy liquidity
lease in our splice status. We ignore it when finalizing the splice: the
only consequence is that we won't store an entry in our DB for that
lease, but the channel will otherwise work correctly.
    @t-bast
    t-bast committed Sep 18, 2024
    Configuration menu
    Copy the full SHA
    ad8e7a3 View commit details
    Browse the repository at this point in the history

  3. Replace pay_to_open with will_add_htlc 

    We replace the previous pay-to-open protocol with a new protocol that
only relies on liquidity ads for paying fees. We simply transmit HTLCs
that cannot be relayed on existing channels with a new message called
`will_add_htlc` that contains all the HTLC data.

The recipient can verify that the HTLC that would match this promise is
valid, and if it wishes to accept that payment, it can trigger a channel
open or a splice to purchase the required inbound liquidity. Once that
transaction completes, the sender will relay HTLCs matching the proposed
`will_add_htlc`, which completes the payment.

If the fees for the inbound liquidity purchase couldn't be paid from the
previous channel balance, they can be taken from the HTLCs relayed after
the funding transaction. When that happens, one side needs to trust that
the other will comply. Each side can independently configure the options
they're comfortable with, depending on whether they trust their peer or
not.
    @t-bast
    t-bast committed Sep 18, 2024
    Configuration menu
    Copy the full SHA
    f0d5447 View commit details
    Browse the repository at this point in the history

  4. Add channelCreationFee to liquidity ads 

    Creating a new channel has an additional cost compared to adding
liquidity to an existing channel: the channel will be closed in the
future, which will require paying on-chain fees. Node operators can
include a `channel-creation-fee-satoshis` in their liquidity ads to
cover some of that future cost.
    @t-bast
    t-bast committed Sep 18, 2024
    Configuration menu
    Copy the full SHA
    3487349 View commit details
    Browse the repository at this point in the history

  5. Clarify received amount before or after fees 

    We clarify some of our event types that previously had an `amount`
field to detail whether this amount includes fees or not.

This impacts:

- SwapInEvents.Accepted
- StoreIncomingPayment.ViaNewChannel
- StoreIncomingPayment.ViaSpliceIn
- Origin.OnChainWallet
- Origin.OffChainPayment

There was an inconsistency in the `ViaSpliceIn` event, where in some
cases we used the received amount, and in others the amount with fees.
    @t-bast
    t-bast committed Sep 18, 2024
    Configuration menu
    Copy the full SHA
    4031190 View commit details
    Browse the repository at this point in the history

  6. Fix payments using FromChannelBalanceForFutureHtlc 

    We forgot to match the `payment_hash` for this payment type, and also
didn't check that the `funding_fee` was `0 msat`.
    @t-bast
    t-bast committed Sep 18, 2024
    Configuration menu
    Copy the full SHA
    0877f36 View commit details
    Browse the repository at this point in the history

  7. Remove minInboundLiquidityTarget 

    We previously forced wallets to purchase additional inbound liquidity
every time an on-chain transaction was created. We now allow wallets
to disable automatic liquidity purchases: the LSP will need to add
enough funds on their side to cover the commitment fees, which the
wallet won't be paying for. But we still make a dummy purchase of 1 sat
to ensure that the liquidity ads flow is used and the wallet refunds
the mining fees paid by the LSP.
    @t-bast
    t-bast committed Sep 18, 2024
    Configuration menu
    Copy the full SHA
    4d8ef0c View commit details
    Browse the repository at this point in the history

  8. Read remote funding rates from their init message 

    Instead of using a hard-coded value from `WalletParams`, we read the
liquidity funding rates from our peer's `init` message.
    @t-bast
    t-bast committed Sep 18, 2024
    Configuration menu
    Copy the full SHA
    1b7e95b View commit details
    Browse the repository at this point in the history