-
Notifications
You must be signed in to change notification settings - Fork 22
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.
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
Remove deprecated serialization format and fields #685
base: master
Are you sure you want to change the base?
Commits on Sep 16, 2024
-
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.
Configuration menu - View commit details
-
Copy full SHA for ab14c59 - Browse repository at this point
Copy the full SHA ab14c59View commit details -
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.
Configuration menu - View commit details
-
Copy full SHA for 526a528 - Browse repository at this point
Copy the full SHA 526a528View commit details -
Replace
pay_to_open
withwill_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.
Configuration menu - View commit details
-
Copy full SHA for 73f76b4 - Browse repository at this point
Copy the full SHA 73f76b4View commit details -
Add
channelCreationFee
to liquidity adsCreating 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.
Configuration menu - View commit details
-
Copy full SHA for fb6a9f6 - Browse repository at this point
Copy the full SHA fb6a9f6View commit details -
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.
Configuration menu - View commit details
-
Copy full SHA for 9a1ab2c - Browse repository at this point
Copy the full SHA 9a1ab2cView commit details -
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`.
Configuration menu - View commit details
-
Copy full SHA for afba34b - Browse repository at this point
Copy the full SHA afba34bView commit details -
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.
Configuration menu - View commit details
-
Copy full SHA for 92b4a66 - Browse repository at this point
Copy the full SHA 92b4a66View commit details -
Read remote funding rates from their
init
messageInstead of using a hard-coded value from `WalletParams`, we read the liquidity funding rates from our peer's `init` message.
Configuration menu - View commit details
-
Copy full SHA for 85f2de9 - Browse repository at this point
Copy the full SHA 85f2de9View commit details -
Add
funding_fee_credit
featureWe add an optional feature that lets on-the-fly funding clients accept payments that are too small to pay the fees for an on-the-fly funding. When that happens, the payment amount is added as "fee credit" without performing an on-chain operation. Once enough fee credit has been obtained, we can initiate an on-chain operation to create a channel or a splice by paying part of the fees from our fee credit. This feature makes more efficient use of on-chain transactions by trusting that our peer will honor our fee credit in the future. The fee credit takes precedence over other ways of paying the fees (from our channel balance or future HTLCs), which guarantees that the fee credit eventually converges to 0.
Configuration menu - View commit details
-
Copy full SHA for aab1d7d - Browse repository at this point
Copy the full SHA aab1d7dView commit details -
Add a parameter to our liquidity policy to limit the amount that can be allocated to fee credit. We don't want a temporary high feerate to cause wallet users to allocate too much funds towards their fee credit, which they may not use later.
Configuration menu - View commit details
-
Copy full SHA for dd5f736 - Browse repository at this point
Copy the full SHA dd5f736View commit details -
Abort splice attempts when balance is too low
If our balance, combined with our fee credit, doesn't allow us to pay the liquidity fees with the payment type we chose, we immediately abort the splice.
Configuration menu - View commit details
-
Copy full SHA for 969560e - Browse repository at this point
Copy the full SHA 969560eView commit details -
Simplify outgoing payment state machine
We previously supported having multiple channels with our peer, because we didn't yet support splicing. Now that we support splicing, we always have at most one active channel with our peer. This lets us simplify greatly the outgoing payment state machine: payments are always made with a single outgoing HTLC instead of potentially multiple HTLCs (MPP). We don't need any kind of path-finding: we simply need to check the balance of our active channel, if any. We may introduce support for connecting to multiple peers in the future. When that happens, we will still have a single active channel per peer, but we may allow splitting outgoing payments across our peers. We will need to re-work the outgoing payment state machine when this happens, but it is too early to support this now anyway. This refactoring makes it easier to create payment onion, by creating the trampoline onion *and* the outer onion in the same function call. This will make it simpler to migrate to the version of trampoline that is currently specified in lightning/bolts#836 where some fields will be included in the payment onion instead of the trampoline onion.
Configuration menu - View commit details
-
Copy full SHA for 59a4a1d - Browse repository at this point
Copy the full SHA 59a4a1dView commit details -
Remove deprecated serialization format and fields
The v4 serialization format was released in July 2023 with better support for backwards-compatibility: the v2 and v3 formats used kotlin's serialization, which prevents us from removing legacy classes and requires additional code whenever we change something in the channel state. Users who haven't migrated their data to the v4 format will not be able to deserialize their channel data: they will need to use a previous version of the app to read their old channel data, write it to the v4 format and then upgrade to the latest version. We also remove a bunch of fields/options that were deprecated a while ago: - legacy channel funding states - unused legacy features - legacy private key generation - legacy node events
Configuration menu - View commit details
-
Copy full SHA for 44d5d86 - Browse repository at this point
Copy the full SHA 44d5d86View commit details