[Lightning-dev] Towards a Market for Liquidity Providers -- Enforcing Minimum Channel Lifetime

ZmnSCPxj ZmnSCPxj at protonmail.com
Mon Nov 12 00:35:55 UTC 2018

Good morning all,

Tangentially related to Pierre question, is  "initiator pays" principle.

Rene actually wondered about whether this would be fair.
Especially, since Licky might very well gather all its dust to provide its side of the funding.
Thinking about this a little more, in the context of a liquidity provider, I provide the below analysis:

If the onchain fees were split somehow between Mercy and Licky, a rational Licky would increase its liquidity fees until it reaches the level where it would still earn the opportunity cost of locking its funds, taking into account the onchain fee that Licky would provide.
Thus in effect the onchain fee from Licky-side would still end up being paid by Mercy, so we may as well be honest and impose "initiator pays".

If the onchain fees were paid only by Mercy, and Licky provides 100 dust outputs, then a rational Mercy would account for the onchain fees incurred plus the liquidity fee as part of the cost of doing business with Licky.
If this cost is too high (regardless of how many outputs Licky provides) then it may be uneconomical for Mercy to do business with that particular Licky and would take its business elsewhere.
(Since Mercy has to sign the funding transaction, and the funding transaction will need to refer to all of Licky-side inputs, Mercy can always not enter into the contract by simply refusing to sign the funding transaction if the onchain fees end up being too high).
Thus Licky would rationally prefer to keep its own funds in as few outputs as possible in order to be more competitive in the liquidity provider market.

So, naively to me, "initiator pays" seems quite reasonable.


Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, November 12, 2018 8:15 AM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning Pierre,
>>> Thus, after Symmetric CSV, we could also add an additional CLTV constraint that determines the minimum channel lifetime.
>> I'm nitpicking, but parties have to exchange the first commitment txes (one for each side) *before* the funding tx is even published. As a consequence, the absolute CLTV delay wouldn't really constrain the duration of the channel, because the timer starts running before the channel is created. Do you think that matters?
> This is quite correct; but it is similar to the case where Mercy (who is buying liquidity) opens the channel, with Licky providing part of the funds, and then Mercy shutting down its node.  As long as the funding transaction gets confirmed and it is possible for Licky to broadcast the commitment transaction, the same analysis applies: Mercy pays Licky to lock its funds, so Licky earns here already, regardless whether Mercy uses the capacity or not.
> Since we (broadly) agreed that initiator of the channel pays onchain fees, Mercy is in control of how fast (or slow) the time is between the two of them agreeing to a specific CLTV blockheight, to when the channel actually opens.  Thus it could be interpreted, that any discrepancy between the time they agree, and the time the channel gets confirmed and starts its onchain lifetime, is equivalent to Mercy shutting down its node for that duration (and the same analysis applies: Mercy has wasted its money on paying Licky for liquidity it didn't use).
> The above analysis hinges on the funding transaction actually getting confirmed, though.
> One possibility is that Mercy could lowball the onchain fee for the funding transaction.  If the mempool becomes backlogged, instead of Mercy then requesting an RBF of the funding transaction, Mercy could just double-spend only its own inputs, invalidating the funding transaction.  This means, that Licky funds have temporarily been locked, then they attempt to open the channel with a low onchain fee, and if that fails then the deal is cancelled and both get their funds back immediately.  Licky then loses all ability to earn (but at least the channel lifetime is no longer imposed in that case).
> The time from when both sides agree to open the channel and exchange signatures for the funding transaction, to the time the funding transaction confirms, may be sensitive due to the possibility of one side unilaterally RBFing their inputs.
> So let us now write the contract in full:
> 1.  Mercy agrees to pay N satoshi to Licky.
> 2.  Licky agrees to have L satoshi locked for use in the channel until blockheight B.
> 3.  Either side may void this contract by paying a miner fee, until the time the funding transaction confirms.
> 4.  Mercy is responsible for getting the funding transaction confirmed.
> Regards,
> ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181112/2b65b824/attachment-0001.html>

More information about the Lightning-dev mailing list