[Lightning-dev] HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes.

Anthony Towns aj at erisian.com.au
Tue Feb 9 08:59:56 UTC 2016

On Tue, Feb 09, 2016 at 10:09:12AM +1030, Rusty Russell wrote:
> Otherwise, if you want to do a unilateral close, there's some game
> theory as you'd rather convince the other side to do it so your own
> funds aren't locked up.

I think the options are:

 a) keep the channel open
 b) they close the channel unilaterally
 c) you close the channel unilaterally
 d) you both close the channel cooperatively

At any point, I believe the preferences are strictly: d > b > c

(b) is better than (c) because of the OP_CSV delay; and (d) is better
than (b) if you can use a lower transaction fee than you use for your
commitment transactions, or spend directly to a useful output address
(opening up a new channel eg).

If you find yourself trying to convince the other person to do (b)
to avoid doing (c) yourself, I think it's a dominating strategy to
simply do (d) -- you prefer that over (b) anyway, and they will prefer
it over (c).

With the current arrangement, I don't think your counterparty can
realistically make any threats: "you'll close the channel? okay,
that's better than me closing it!" and "you'll close the channel
unilaterally? well, that's a lot worse for you as it is for me,
so whatever".

With an OP_CSV on both sides of HTLCs, you can make a somewhat
realistic threat: "if you don't pay me $x to do a cooperative close,
I'll close unilaterally which will lock your funds up. sure you can
close unilaterally yourself, but your funds will still be locked up that
way too."

So changing seems like it would make things marginally worse, but no
better, to me.


More information about the Lightning-dev mailing list