<div>Good morning Pierre,<br></div><div><br></div><blockquote type="cite" class="protonmail_quote"><div dir="auto"><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Thus, after Symmetric CSV, we could also add an additional CLTV constraint that determines the minimum channel lifetime.<br></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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?&nbsp;<br></div></div></blockquote><div><br></div><div>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.&nbsp; 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.<br></div><div><br></div><div>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.&nbsp; 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).<br></div><div><br></div><div>The above analysis hinges on the funding transaction actually getting confirmed, though.<br></div><div><br></div><div>One possibility is that Mercy could lowball the onchain fee for the funding transaction.&nbsp; 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.&nbsp; 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.&nbsp; Licky then loses all ability to earn (but at least the channel lifetime is no longer imposed in that case).<br></div><div><br></div><div>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.<br></div><div><br></div><div>So let us now write the contract in full:<br></div><div><br></div><div>1.&nbsp; Mercy agrees to pay N satoshi to Licky.<br></div><div>2.&nbsp; Licky agrees to have L satoshi locked for use in the channel until blockheight B.<br></div><div>3.&nbsp; Either side may void this contract by paying a miner fee, until the time the funding transaction confirms.<br></div><div>4.&nbsp; Mercy is responsible for getting the funding transaction confirmed.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div><br></div><div><br></div><div><br></div>