0

In the Lightning Network Paper (https://lightning.network/lightning-network-paper.pdf), Breach Remedy Transactions seem to require signatures by both channel members. I infer this from this description in the paper:

When a new pair of Commitment Transactions (C2a/C2b) is agreed upon, both parties will sign and exchange signatures for the new Commit- ment Transaction, then invalidate the old Commitment Transaction. This invalidation occurs by having both parties sign a Breach Remedy Trans- action (BR1), which supersedes the Revocable Delivery Transaction (RD1). Each party hands to the other a half-signed revocation (BR1) from their own Revocable Delivery (RD1), which is a spend from the Commitment Transac- tion. The Breach Remedy Transaction will send all coins to the counterparty within the current balance of the channel.

(Emphasis by me.)

I do, however, not understand why this is a requirement. It seems to me that it's possible to design the Revocable Sequence Maturity Contract in such a way that only the signature of the Breach Remedy Transaction's issuer is required, not additionally the one of the redeeming party.

Is my notion correct? If not: Why not?

Murch
  • 71,155
  • 33
  • 180
  • 600
UTF-8
  • 3,214
  • 1
  • 14
  • 28

1 Answers1

0

If we assume "half-signed" implies that both parties sign the transaction, then the Breach Remedy transaction would also include the spend from the other output in the commitment transaction which would then also require Bob's signature. This logically makes sense (but is not explicitly stated in the paper) as it would reduce transaction fees and consolidate UTXOs. But yes, you are correct, there is no need to have both parties sign the Breach Remedy transaction.

The current protocol design actually does away entirely with the Breach Remedy and Revocable Delivery Transactions by using special scripts which enforce the rules that those transactions would enforce by existing. This script uses a relative lock time (with OP_CHECKSEQUENCEVERIFY) to enforce the Revocable Delivery rule. It also uses a revocation key which can be generated by the party performing the revocation after a commitment transaction has been revoked, thus doing away with the Breach Remedy transaction. The output script construction is described here.

Andrew Chow
  • 67,209
  • 5
  • 76
  • 149
  • I assume that in your scenario, Bob is the one who broadcasts an old Commitment TX. Please inform me if this assumption is incorrect. This means that some of the payment channel's money goes to Alice anyway. Some goes to Bob. When Alice broadcasts her Breach Remedy TX, she only has to direct the funds which are on their way to Bob to her. This requires Bob's signature. That the Breach Remedy TX Alice got from Bob is half-signed implies that it also requires Alice's signature before being ready to be included in a block. Why is Alice's signature required to redirect Bob's funds? – UTF-8 Dec 26 '17 at 20:06
  • No, in this scenario it is Alice that is broadcasting the old commitment transaction and Bob that is broadcasting the Breach Remedy transaction. The Breach Remedy transaction needs both Alice and Bob to sign because it spends from both outputs (both Alice's and Bob's outputs) in the commitment transaction even though it does not need to. – Andrew Chow Dec 26 '17 at 20:20
  • Do you know where it says that in the Lightning Network Paper? Do you of any reason it was chosen this way? – UTF-8 Dec 26 '17 at 20:46
  • It is not part of the paper at all. A reason for doing the transaction as such would be do consolidate UTXOs and reduce transaction fees. – Andrew Chow Dec 26 '17 at 20:54
  • I'm sorry but I don't see where the papers says that a Breach Remedy TX spends the output of the non-betraying party's Delivery TX. In fact, figures 8, 9, and 14 don't look like that at all. Can you please point out where it says that? – UTF-8 Dec 26 '17 at 22:45
  • Did you even read my comment or my revised answer? "** It is not part of the paper**" – Andrew Chow Dec 26 '17 at 22:54
  • I understood your comment as though you're saying that the paper does not state a reason for consolidation but does state that consolidation happens. Figures 8, 9, and 14 seem to contradict this as they do not show an arrow pointing from the Delivery TX of the non-betraying party to the to their Breach Remedy TX. – UTF-8 Dec 26 '17 at 22:59
  • If I understand you correctly, you're saying that if the retaliating party doesn't want care about their UTXOs being consolidated, there is no need for a signature by the retaliating party to be required. After some thinking, posting a different question [which you also answered](https://bitcoin.stackexchange.com/a/67363/29893), and some more thinking I came to the conclusion that I don't understand how that would work. – UTF-8 Jan 05 '18 at 00:04
  • If the betraying party Bob is capable of creating BR1b in figure 8 with only his signature being required, he is able to create a second Breach Remedy TX BR1bEvil which sends the money to one of his own addresses. Of course he still gives BR1b to Alice but when he betrays, he can broadcast BR1bEvil before Alice broadcasts BR1b, effectively ending the payment channel immediately with fair pay-out. This contradicts the paper's statement that one-sided closure of a payment channel comes with a waiting period. I therefore think sth is wrong and that 2 signatures really are required. – UTF-8 Jan 05 '18 at 00:06
  • It may be that this was not considered in the initial paper and thus is a flaw in the original design (IIRC there are actually a few flaws). However the current design laid out by the LN specification resolves this issue where the key necessary for creating the breach remedy transaction is only known to the party that would be creating it. – Andrew Chow Jan 05 '18 at 00:31