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?
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 – 2017-12-26T20:06:51.050
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 – 2017-12-26T20:20:51.370
Do you know where it says that in the Lightning Network Paper? Do you of any reason it was chosen this way? – UTF-8 – 2017-12-26T20:46:39.593
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 – 2017-12-26T20:54:52.567
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 – 2017-12-26T22:45:08.593
Did you even read my comment or my revised answer? " It is not part of the paper" – Andrew Chow – 2017-12-26T22:54:58.720
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 – 2017-12-26T22:59:22.190
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, and some more thinking I came to the conclusion that I don't understand how that would work.
– UTF-8 – 2018-01-05T00:04:13.447If 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 – 2018-01-05T00:06:19.817
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 – 2018-01-05T00:31:15.310