blip-0041: channel funding fee credit #41
Conversation
Onboarding users to the lightning network is hard, because opening a channel requires paying on-chain fees and allocating capital, hoping that it will be used to earn routing fees. It is not economical nor sustainable to open channels for users that receive a tiny amount and may not use the network frequently enough. Wallet providers usually work around this issue by requiring users to receive a large enough first payment to pay on-chain fees for their channel. However, a collection of unrelated tiny payments received over a period of time may be enough to justify creating a channel. We thus introduce a funding fee credit, that lets users prepay for future channel(s) by proactively revealing htlc preimages for small payments. When that fee credit reaches a sufficient amount, it is used by the remote node to cover the on-chain costs of opening a channel or splicing additional liquidity.
t-bast
force-pushed
the
funding-fee-credit
branch
from
6b72ee5 to
043b698
Compare
| types. We collect fees from the fee credit first, which ensures that it | ||
| converges to 0. | ||
|
|
||
| The node sending `add_fee_credit` is trusting its peer to correctly keep track |
There was a problem hiding this comment.
Can those that accept the free credit use it to make future payments with the credit without an on chain channel? I guess with that it starts to resemble the old "hosted channels" concept.
There was a problem hiding this comment.
I guess with that it starts to resemble the old "hosted channels" concept.
That's why we don't want to go down that road...if you need this, just use a custodial wallet. Here we only introduce purchasing on-chain fees in advance, this is purposefully much more restricted to limit the additional trust required.
|
There's a lot here, but it seems like we could instead just have a 0conf channel with a fake/unbroadcasted funding transaction, then when the "channel" gets enough funds to pay for the open, the fundee simply sends the funder an HTLC back with the required amount and the funder dual-funding-"RBF"'s the original funding to actually fund the channel. That would avoid ~all the new messages, no? |
It's not just for channel open, this will happen for splices as well. But I did try what you're proposing first after our discussion from the Tuscany Lightning Summit, and once you get down to the nitty-gritty details, it's actually very complex (much more complex IMO than what I'm proposing here). I'd be happy to be proven wrong, but someone needs to fully implement and specify this alternative protocol to prove that it's simpler and better, and I failed when trying that 😅 |
Adds support for liquidity-ads based protocol for on-the-fly liquidity as specified in lightning/blips#36 and lightning/blips#41, implemented respectively in ACINQ/lightning-kmp#649 and ACINQ/lightning-kmp#660. ### Lightning-kmp update Phoenixd now uses the main branch of `lightning-kmp` (v1.8.0). ### Database update - `LiquidityAds.Lease` is replaced by `LiquidityAds.Purchase`, so we need to update the liquidity table. - the `receivedWith` data have been updated in lightning-kmp, and we need a new `Part.Htlc.V1` object that may contain a `LiquidityAds.FundingFee`. With the `Lease->Purchase` change, we've updated our pattern for versioning database objects. We now have `asDb()` & `asCanonical()` mapping methods and store the type of the db object inside the json (which means we don't need the `type` column anymore, except for convenience). --------- Co-authored-by: pm47 <[email protected]>
Adds support for liquidity-ads based protocol for on-the-fly liquidity as specified in lightning/blips#36 and lightning/blips#41, implemented respectively in ACINQ/lightning-kmp#649 and ACINQ/lightning-kmp#660. ### Lightning-kmp update Phoenixd now uses the main branch of `lightning-kmp` (v1.8.0). ### Database update - `LiquidityAds.Lease` is replaced by `LiquidityAds.Purchase`, so we need to update the liquidity table. - the `receivedWith` data have been updated in lightning-kmp, and we need a new `Part.Htlc.V1` object that may contain a `LiquidityAds.FundingFee`. With the `Lease->Purchase` change, we've updated our pattern for versioning database objects. We now have `asDb()` & `asCanonical()` mapping methods and store the type of the db object inside the json (which means we don't need the `type` column anymore, except for convenience). --------- Co-authored-by: pm47 <[email protected]>
Onboarding users to the lightning network is hard, because opening a channel requires paying on-chain fees and allocating capital, hoping that it will be used to earn routing fees. It is not economical nor sustainable to open channels for users that receive a tiny amount and may not use the network frequently enough.
Wallet providers usually work around this issue by requiring users to receive a large enough first payment to pay on-chain fees for their channel.
However, a collection of unrelated tiny payments received over a period of time may be enough to justify creating a channel. We thus introduce a funding fee credit, that lets users prepay for future channel(s) by proactively revealing htlc preimages for small payments. When that fee credit reaches a sufficient amount, it is used by the remote node to cover the on-chain costs of opening a channel or splicing additional liquidity.