<p>You are right that in the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#to_local-output" rel="nofollow noreferrer">BOLT3 Scripts</a> the revocation path pays only to a single public key, the <code>revocationpubkey</code>.</p>
<p>In order to keep the same restriction with a single pubkey, the <code>revocationpubkey</code> is derived based on both a secret generated by the local node and one by the remote node.<br />
Without the part of the secret only known to the local node, the remote node cannot spend from this path. In order to revoke a commitment, the local shares this secret to the remote node effectively allowing it to steal all the funds should it broadcast this transaction.</p>
<p>See <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#revocationpubkey-derivation" rel="nofollow noreferrer">the <code>revocationpubkey</code> derivation specification in BOLT3</a>.</p>

CC BY-SA 4.0
2021-07-12T18:33:13.260Z
I think it is worthwhile to add that this trick works as going from private keys to public keys is done by multipling the generator point with a private key and that this process is a group homomorphism. Eg: `(p+q)*G=pG+qG=P+Q` where capital letters are points of the elliptic curve and lower letters are scalars in the additative group of a prime field
Rene Pickhardt
CC BY-SA 4.0
2021-07-12T09:20:36.803Z
2021-07-12T09:20:36.803Z
Antoine Poinsot
<p>The original Lightning Paper required both signatures for the Breach Remedy Tx (see also <a href="https://bitcoin.stackexchange.com/questions/66280/double-signature-requirement-of-breach-remedy-transaction">this Q</a>) but according to the BOLT #3 specs the Breach Remedy Tx only seems to hinge on the <code>revocationpubkey</code> for which Alice will share her revocation secret upon establishing a new Commitment Tx.</p>
<p>I'm wondering if I am missing some detail here.</p>

<lightning-network><lightning-rfc>
Does the Breach Remedy Tx hinge on the remote party's revocation secret exclusively?
gijswijs
# Does the Breach Remedy Tx hinge on the remote party's revocation secret exclusively?

(Asked by: username_0 on 2021-07-12)

The original Lightning Paper required both signatures for the Breach Remedy Tx (see also [this Q](https://bitcoin.stackexchange.com/questions/66280/double-signature-requirement-of-breach-remedy-transaction)) but according to the BOLT #3 specs the Breach Remedy Tx only seems to hinge on the `revocationpubkey` for which Alice will share her revocation secret upon establishing a new Commitment Tx.

I'm wondering if I am missing some detail here.

**Tags:** lightning-network, lightning-rfc


---

## 1 answers

### Answer by username_1 on 2021-07-12. Score: 1 | Accepted answer

You are right that in the [BOLT3 Scripts](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#to_local-output) the revocation path pays only to a single public key, the `revocationpubkey`.

In order to keep the same restriction with a single pubkey, the `revocationpubkey` is derived based on both a secret generated by the local node and one by the remote node.  
Without the part of the secret only known to the local node, the remote node cannot spend from this path. In order to revoke a commitment, the local shares this secret to the remote node effectively allowing it to steal all the funds should it broadcast this transaction.

See [the `revocationpubkey` derivation specification in BOLT3](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#revocationpubkey-derivation).

> **Comments:**
> **username_2**: I think it is worthwhile to add that this trick works as going from private keys to public keys is done by multipling the generator point with a private key and that this process is a group homomorphism. Eg: `(p+q)*G=pG+qG=P+Q` where capital letters are points of the elliptic curve and lower letters are scalars in the additative group of a prime field  

---

