<p>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.</p>

<p>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 <code>OP_CHECKSEQUENCEVERIFY</code>) 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 <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#to_local-output" rel="nofollow noreferrer">here</a>.</p>

CC BY-SA 3.0
2017-12-26T20:06:51.050Z
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
CC BY-SA 3.0
2017-12-26T20:20:51.370Z
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.
Ava Chow
CC BY-SA 3.0
2017-12-26T20:46:39.593Z
Do you know where it says that in the Lightning Network Paper? Do you of any reason it was chosen this way?
UTF-8
CC BY-SA 3.0
2017-12-26T20:54:52.567Z
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.
Ava Chow
CC BY-SA 3.0
2017-12-26T22:45:08.593Z
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
CC BY-SA 3.0
2017-12-26T22:54:58.720Z
Did you even read my comment or my revised answer? "** 
It is not part of the paper**"
Ava Chow
CC BY-SA 3.0
2017-12-26T22:59:22.190Z
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
CC BY-SA 3.0
2018-01-05T00:04:13.447Z
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
CC BY-SA 3.0
2018-01-05T00:06:19.817Z
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
CC BY-SA 3.0
2018-01-05T00:31:15.310Z
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.
Ava Chow
CC BY-SA 3.0
2017-12-26T17:45:32.377Z
2017-12-26T20:55:58.380Z
2017-12-26T20:55:58.380Z
Ava Chow
<p>In the Lightning Network Paper (<a href="https://lightning.network/lightning-network-paper.pdf" rel="nofollow noreferrer">https://lightning.network/lightning-network-paper.pdf</a>), Breach Remedy Transactions seem to require signatures by both channel members. I infer this from this description in the paper:</p>

<blockquote>
  <p>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 <strong>half-signed revocation</strong> (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.</p>
</blockquote>

<p>(Emphasis by me.)</p>

<p>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.</p>

<p>Is my notion correct? If not: Why not?</p>

<lightning-network><ln-penalty-transaction>
Double signature requirement of Breach Remedy Transaction
UTF-8
# Double signature requirement of Breach Remedy Transaction

(Asked by: username_0 on 2017-12-23)

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?

**Tags:** lightning-network, ln-penalty-transaction


---

## 1 answers

### Answer by username_1 on 2017-12-26. Score: 0 | Accepted answer

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](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#to_local-output).

> **Comments:**
> **username_0**: 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?  
> **username_1**: 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.  
> **username_0**: Do you know where it says that in the Lightning Network Paper? Do you of any reason it was chosen this way?  
> **username_1**: 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.  
> **username_0**: 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?  
> **username_1**: Did you even read my comment or my revised answer? "**  It is not part of the paper**"  
> **username_0**: 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.  
> **username_0**: 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.  
> **username_0**: 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.  
> **username_1**: 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.  

---

