Double signature requirement of Breach Remedy Transaction 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?
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.