Published on: 2018-11-12T00:35:55+00:00
In a Lightning-dev discussion, ZmnSCPxj brings up the "initiator pays" principle in relation to liquidity providers. The analysis suggests that the liquidity provider would increase its fees until it reaches a level where it still earns the opportunity cost of locking its funds, taking into account the onchain fee that the provider would provide. This means that the onchain fee from the liquidity provider's side would still be paid by the buyer of liquidity. On the other hand, if the onchain fees were only paid by the party buying liquidity, it would account for the onchain fees incurred plus the liquidity fee as part of the cost of doing business with the liquidity provider. If this cost is too high, it may be uneconomical for the party buying liquidity to do business with that particular liquidity provider.ZmnSCPxj also discusses how parties have to exchange the first commitment txes (one for each side) before the funding tx is 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. However, if the funding transaction gets confirmed and it is possible for one party to broadcast the commitment transaction, then the same analysis applies. The initiator of the channel pays onchain fees and controls how fast or slow the time is between both parties agreeing to a specific CLTV blockheight to when the channel opens.The possibility of lowballing the onchain fee for the funding transaction and double-spending only one's own inputs to invalidate the funding transaction is discussed, which would mean the liquidity provider loses all ability to earn. 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 replacing-by-fee their inputs.The full contract for this scenario is presented: Mercy agrees to pay N satoshi to the liquidity provider, who agrees to have L satoshi locked for use in the channel until block height B. Either side may void this contract by paying a miner fee until the funding transaction confirms, and Mercy is responsible for getting the funding transaction confirmed.In another conversation between ZmnSCPxj and Pierre, they discuss the possibility of adding an additional CLTV constraint to determine the minimum channel lifetime after Symmetric CSV. However, Pierre raises a concern that parties have to exchange the first commitment txes before the funding tx is published, which means the absolute CLTV delay wouldn't really constrain the duration of the channel as the timer starts running before the channel is created. Pierre asks if ZmnSCPxj thinks this matters.The thread also discusses the concept of dual-funding and a liquidity market for providing incoming capacity. The proposal suggests that the contract for purchasing liquidity should not only specify the amount to be allocated for capacity but also some duration for how long that capacity is to be allocated. This will help determine if the closure of a channel is improper or not. To impose a minimum lifetime on a channel, an additional CLTV constraint that determines the minimum channel lifetime can be added after symmetric CSV. The commitment transaction can be broadcast at any time, as it has no nLockTime.It is mentioned that if Licky pretends to sleep and does not respond, it gains no additional money or utility. In case of emergency, Licky has the ability to enforce on-chain. If Mercy broadcasts the commitment transaction as soon as it is signed, it ties up Licky's funds, and Licky cannot earn routing fees. The purpose of Mercy performing this exercise is to receive money. If Licky disposes of its obligation without having most of its money tied to the channel, then the obligation is transferred to Randy. If an actual physical bolt of lightning were to strike Licky, then Mercy gets no incoming capacity, and the contract is effectively voided.
Updated on: 2023-07-31T20:41:06.920854+00:00