2

I am reading the Lightning Network paper and noticed that when describing bidirectional payment channels, the authors used "Breach Remedy transactions" and the exchange of the two parties' private keys to discourage any of the parties to broadcast an old commitment transaction. This is indeed an effective solution, however I read in more than one place (e.g. here, here) that this is actually achieved through hashlocks (i.e. the two parties create hashlocked transactions from their commitment transactions and share the hashlock secret instead of exchanging their private keys to discourage the broadcasting of previous commitment transactions when they update the channel). In the paper, hashlocks are used when the bidirectional payment channels are used to relay payments among more than two nodes, however they are not used for payment channels between two nodes.

So the question is: are commitment transactions between two nodes revoked through hashlocks or through private keys exchange?

1 Answer 1

2

So the question is: are commitment transactions between two nodes revoked through hashlocks or through private keys exchange?

Either way will work, but hashlocks are simpler. They're described in section 4 of the paper you linked. In a private key exchange-based system, you need to store every breach remedy transaction, (about 250 bytes) but in a hashlock system, you only need 20 bytes for each preimage.

You don't need to store every preimage, either. Murch explains and links a system to store every hash in a channel with 64*20 bytes of memory at most here: What is a hash pre-image as it is used for the breach remedy?

2
  • Thank you for the insight! So I have one more question: is there any reason why in the LN paper they considered hashlocks for multihop channels but did not consider them for two-parties channels? Commented Mar 2, 2017 at 0:04
  • I think they do consider hashlocks for two party channels. That's what they're describing in 4.2.
    – Nick ODell
    Commented Mar 2, 2017 at 0:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.