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

Rusty Russell rusty at rustcorp.com.au
Tue Feb 9 23:14:46 UTC 2016


Anthony Towns <aj at erisian.com.au> writes:
> 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.

Fair point.  The issue will improve when we have close with outstanding
HTLCs.  Meanwhile it disturbs me that the party which goes offline pays
the least penalty; their counterparties have their funds tied though.

Cheers,
Rusty.


More information about the Lightning-dev mailing list