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?

1 Answer 1


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.

  • 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
    Commented Dec 26, 2017 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.
    – Ava Chow
    Commented Dec 26, 2017 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
    Commented Dec 26, 2017 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.
    – Ava Chow
    Commented Dec 26, 2017 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
    Commented Dec 26, 2017 at 22:45

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.