[Lightning-dev] Transaction revocation within transaction malleability via anyone-can-revoke hashlocks

[Rusty Russell]

ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> Good morning Rusty,
>
>>ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
>>> From what I can gather so far, it seems, the issue of transaction revocation even with transaction malleability appears to be solved. Although, I want to know, is my idea (which support selfish untrustworthy watchers) better than what Lightning now has? Or has different tradeoffs? It seems to me, at first glance, if the revocation key in my idea is not publicized but sent only to the counterparty, it is effectively equivalent to the current technique. But the receiving counterparty has the option of publishing this revocation key in order to allow anyone to enforce and get free money, even with malleability.
>>
>>That's true, actually.
>
> Do you think it's a good idea to publish revocation keys, and have the condition (Alice && revokekey) || (CSV + 1 && revokekey) || (CSV + 2 && Bob)? That way, you can revoke immediately if iyu are online, or anyone (including Bob) can poach it if you let the CSV+1 lapse (the hope is, Bob's probability of poaching via this method is low, so, it will disincentivize Bob). If you don't want anyone to poach the money via anyone-can-revoke, you can keep the revocation key to yourself, but you must ensure you can get online before the CSV+2 period arrives.

I think it's a good idea to use segwit, and not rely on these kind of
games...

>>You can certainly have trusted watchers know
>>your revocation keys (and they have a very compact form, so the storage
>>is ~log2(num-transactions).
>
> Maybe, you mean, counterparty's revocation key? (sorry, I want to confirm my understanding of low level of Lightning Network)

Ah, terminology?  I meant A could share the key which allows A to spend
B's old commitment transactions.

Cheers,
Rusty.