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

ZmnSCPxj ZmnSCPxj at protonmail.com
Wed Apr 26 19:16:47 UTC 2017


One primitive that is necessary for bidirectional channels is revocable transactions. Briefly, in the absence of transaction malleability, in order to generate a revocable output, the output is encumbered such that either the receiver can receive the output after some time (via CSV opcode), or the output may be signed by both the sender and receiver. If the receiver wants to provide a proof of revocation, the receiver constructs a revocation transaction spending the output and sending it to the sender. The receiver signs that transaction and gives it to the sender. If the receiver subsequently attempts to realize the revoked output by broadcasting its transaction on the public blockchain, the sender may revoke it by sending the revocation transaction.

However, in the presence of malleability, a fraudluent receiver may simply malleate the transaction producing the output. The output will then be referred to via a different txid, invalidating the existing revocation transaction.

Another issue with this style of revocable transactions is that it is still possible for the receiver to defraud the sender via a two-prong attack: the sender DDOS'es or otherwise prevents the sender from successfully sending the revocation transaction, and transmits the revoked transaction on the network. If the receover is capable of keeping the sender off-network until the CSV expires, the receiver may defraud the sender. It would be desirable if a separate bounty hunter may be hired in order to prevent fraud, so that the fraudulent receiver needs to keep many more agents away from the Bitcoin network.

Fortunately, a single solution fixes both issues.

When constructing a revocable output, the receiver first generates a secure truely random number, the revocation key. The revocation lock is the hash of the revocation key (i.e. hashlock). The revocable output may be spent in any of the following conditions:

1. After CSV +2 days, by the receiver.

2. By the sender, if the sender can show the revocation key.

3. After CSV +1 days, by anyone who can show the revocation key (anyone can revoke).

To revoke the revocable output, the receiver of the revocable output publishes the revocation key to the sender and to any interested participants in the Lightning Network.

If the output has not been revoked, the receiver has never published the revocation key and simply needs to wait 2 days to spend.

If the output has been revoked, and the receiver attempts to realize the revoked output on the Bitcoin network, if the sender is online, it can construct a revocation transaction by itself by signing the transaction and showing the published revocation key.

In addition, if the sender is unavailable or disconnected, after 1 day, anyone who has heard and kept the revocation key may claim the receiver's coins. Thus, the receiver, in order to use a revoked output, needs to prevent everyone to whom the revocation key has been sent from the Bitcoin network during the 1 day between the CSV+1 and CSV+2 periods.

I would like to know if my consideration is correct or if I have missed or incorrectly analyzed some aspect of transaction revocation.

I hope for your discussion.

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170426/01bcd88f/attachment.html>


More information about the Lightning-dev mailing list