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
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
