lightning-dev

Transaction revocation within transaction malleability via anyone-can-revoke hashlocks

Transaction revocation within transaction malleability via anyone-can-revoke hashlocks

Original Postby Rusty Russell

Posted on: May 5, 2017 02:36 UTC

In this conversation, ZmnSCPxj discusses the issue of transaction revocation with Rusty.

From what ZmnSCPxj has gathered, it seems that the issue has been solved even with transaction malleability. However, ZmnSCPxj proposes an idea that supports selfish untrustworthy watchers and wonders if it is better than what Lightning Network currently has or if it has different tradeoffs. At first glance, ZmnSCPxj believes that their idea is equivalent to the current technique if the revocation key is not publicized but sent only to the counterparty. The receiving counterparty has the option of publishing the revocation key in order to allow anyone to enforce and get free money, even with malleability. ZmnSCPxj then asks Rusty if it's a good idea to publish revocation keys and have the condition that allows revocation immediately if you are online or anyone can poach it if you let the CSV+1 lapse. Rusty responds that it might be a good idea to use segwit instead of relying on these kinds of games. Rusty suggests that trusted watchers can know your revocation keys, which have a very compact form and require ~log2(num-transactions) storage. ZmnSCPxj clarifies that they meant A could share the key, which allows A to spend B's old commitment transactions.