<blockquote>
  <p>Why not simply have some random numbers in place of RK_A and RK_B that only A and B knows and which are later exchanged when TX_A and TX_B need to be invalidated??</p>
</blockquote>

<p>Let us assume, the transaction is structured wherein A and B generates random secrets. For every revocation that happens, the nodes will have to store the secret for each commitment that is signed. Each HTLC offered and redeemed, involve 2 commitment revocations. So, a node will have to store a huge database of all the secrets, ordering them in the way the transaction is signed. With the current method, we have a basepoint from which the secret is generated so that we do not have to store each key individually, but derive it based on the <code>revocation_basepoint</code> and <code>per_commitment_secret</code> which are <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#per-commitment-secret-requirements" rel="nofollow noreferrer">generated deterministically</a> and <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#efficient-per-commitment-secret-storage" rel="nofollow noreferrer">saved compactly</a>.</p>

<blockquote>
  <p>Why commitment transactions can't simply be HTLCs instead of contracts revocable by having the second half of the Revocable Private Key?</p>
</blockquote>

<p>All lightning transactions are constructed in a way that they are completely valid on the  Bitcoin main chain. If you simply create transactions wherein the outputs are unlocked with a pre-image, then it opens itself up to men-in-the-middle attacks. In case of an on-chain settlement, when the transaction is broadcasted containing this input which is spent only with a pre-image, then the the node relaying or the one mining, will know this preimage and just change the outputs of the transaction to the ones paying themselves. That is the reason, we use signature verification, so that the person spending the input signs the entire transaction so none of it can be modified.</p>

<p>If you are wondering, then how HTLCs are offered for lightning payments, it is not that simple as a simple private key. Below is a script that shows the commitment that the other party signs to a transaction I am holding when I am offering the HTLC.</p>

<pre><code># To remote node with revocation key
OP_DUP OP_HASH160 &lt;RIPEMD160(SHA256(revocationpubkey))&gt; OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    &lt;remote_htlcpubkey&gt; OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP &lt;local_htlcpubkey&gt; 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 &lt;RIPEMD160(payment_hash)&gt; OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF
</code></pre>

<p>If we have all outputs constructed in this way, then the transaction size will be unnecessarily large, and also will have inefficient key management as I mentioned in the previous section.</p>

CC BY-SA 4.0
2019-06-19T16:13:29.720Z
But if I understand correctly the `revocationprivkey` would also have to be stored for every transaction, since `per_commitment_secret` would have to be regenerated for every new transaction?
spacemonkey
CC BY-SA 4.0
2019-06-19T16:56:41.600Z
@spacemonkey not necessarily; the keys can be calculated from a compact representation. For key generation, you just generate a seed, and then use an index to bit flip and hash the result. For storage, only one secret for each unique prefix need be saved; in effect, the number of trailing 0s is counted, and this determines where in the storage array the secret is stored. You can read more key storage in BOLT #3 here: https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#efficient-per-commitment-secret-storage
Ugam Kamat
CC BY-SA 4.0
2019-06-19T15:12:27.487Z
2019-06-19T17:09:49.937Z
2019-06-19T17:09:49.937Z
Ugam Kamat
<p>Why commitment transactions can't simply be HTLCs instead of contracts revocable by having the second half of the Revocable Private Key? I mean, why bother to create a Revocable Public Key from two halves of Alice's and Bob's private keys and when invalidating a transaction sharing the other half, when both Alice and Bob could create two transactions, both revocable with two separate keys known only to Alice and Bob, which later would be exchanged in order to invalidate old transactions?</p>

<h2>Edit: My current understanding of how commitment transactions work</h2>

<p>Both Alice (A) and Bob (B) create opposite transactions:</p>

<pre><code>TX_A:

5 BTC -&gt; B
if RK_A
  5 BTC -&gt; B
else if 1k blocks later
  5 BTC -&gt; A
(Signed by B)

TX_B:

5 BTC -&gt; A
if RK_B
  5 BTC -&gt; A
else if 1k blocks later
  5 BTC -&gt; B
(Signed by A)   
</code></pre>

<p>Where RK_A is A's revocation key. Now if TX_A and TX_B are valid, neither B has RK_B, nor A has RK_B. Therefore, both of them can sign their respective transactions and "get out" of this channel after 1k blocks without risk of loosing all their BTC.</p>

<p>However, once both A and B decide to forget about the old balance they have to invalidate TX_A and TX_B. They do this by A revealing RK_A to B and B revealing RK_B to A. This way, if for instance A signs TX_A and broadcasts it to the Bitcoin network, B can provide RK_A and claim additional 5 BTC.</p>

<hr>

<p>Now the process of creating and revealing RK_X seems to be involved, and my questions therefore is, why not simply have some random numbers in place of RK_A and RK_B that only A and B knows and which are later exchanged when TX_A and TX_B need to be invalidated?</p>

CC BY-SA 4.0
2019-06-19T14:25:19.103Z
Hey well come to our community and great that you are interested in the Lightning Network. I would love to answer your question and I get the gist of it but I don't really get what exactly your are asking for. Would you be so kind to elaborate or edit your question or maybe specify a little bit more the mechanism that you think could be used to invalidate old channel state?
Rene Pickhardt
CC BY-SA 4.0
2019-06-19T14:43:45.800Z
Hi @RenePickhardt, I have added some additional info, hope this helps :)
spacemonkey
CC BY-SA 4.0
2019-06-19T15:04:25.077Z
Thanks for extending your question. In deed I thought you meant something different. However again I am confused. What is the difference between a private revokation key and a random number? In both cases the data needs to be transported vital BOLT 2 in the revoke_and_ack message
Rene Pickhardt
<lightning-network><hash-time-locked-contract>
HTLCs and commitment transactions
spacemonkey
# HTLCs and commitment transactions

(Asked by: username_0 on 2019-06-19)

Why commitment transactions can't simply be HTLCs instead of contracts revocable by having the second half of the Revocable Private Key? I mean, why bother to create a Revocable Public Key from two halves of Alice's and Bob's private keys and when invalidating a transaction sharing the other half, when both Alice and Bob could create two transactions, both revocable with two separate keys known only to Alice and Bob, which later would be exchanged in order to invalidate old transactions?

## Edit: My current understanding of how commitment transactions work

Both Alice (A) and Bob (B) create opposite transactions:

```
TX_A:

5 BTC -> B
if RK_A
  5 BTC -> B
else if 1k blocks later
  5 BTC -> A
(Signed by B)

TX_B:

5 BTC -> A
if RK_B
  5 BTC -> A
else if 1k blocks later
  5 BTC -> B
(Signed by A)   

```

Where RK\_A is A's revocation key. Now if TX\_A and TX\_B are valid, neither B has RK\_B, nor A has RK\_B. Therefore, both of them can sign their respective transactions and "get out" of this channel after 1k blocks without risk of loosing all their BTC.

However, once both A and B decide to forget about the old balance they have to invalidate TX\_A and TX\_B. They do this by A revealing RK\_A to B and B revealing RK\_B to A. This way, if for instance A signs TX\_A and broadcasts it to the Bitcoin network, B can provide RK\_A and claim additional 5 BTC.

---

Now the process of creating and revealing RK\_X seems to be involved, and my questions therefore is, why not simply have some random numbers in place of RK\_A and RK\_B that only A and B knows and which are later exchanged when TX\_A and TX\_B need to be invalidated?

**Tags:** lightning-network, hash-time-locked-contract

> **Comments:**
> **username_1**: Hey well come to our community and great that you are interested in the Lightning Network. I would love to answer your question and I get the gist of it but I don't really get what exactly your are asking for. Would you be so kind to elaborate or edit your question or maybe specify a little bit more the mechanism that you think could be used to invalidate old channel state?  
> **username_0**: Hi @username_1, I have added some additional info, hope this helps :)  
> **username_1**: Thanks for extending your question. In deed I thought you meant something different. However again I am confused. What is the difference between a private revokation key and a random number? In both cases the data needs to be transported vital BOLT 2 in the revoke_and_ack message  

---

## 1 answers

### Answer by username_2 on 2019-06-19. Score: 0 | Accepted answer

> Why not simply have some random numbers in place of RK\_A and RK\_B that only A and B knows and which are later exchanged when TX\_A and TX\_B need to be invalidated??

Let us assume, the transaction is structured wherein A and B generates random secrets. For every revocation that happens, the nodes will have to store the secret for each commitment that is signed. Each HTLC offered and redeemed, involve 2 commitment revocations. So, a node will have to store a huge database of all the secrets, ordering them in the way the transaction is signed. With the current method, we have a basepoint from which the secret is generated so that we do not have to store each key individually, but derive it based on the `revocation_basepoint` and `per_commitment_secret` which are [generated deterministically](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#per-commitment-secret-requirements) and [saved compactly](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#efficient-per-commitment-secret-storage).

> Why commitment transactions can't simply be HTLCs instead of contracts revocable by having the second half of the Revocable Private Key?

All lightning transactions are constructed in a way that they are completely valid on the Bitcoin main chain. If you simply create transactions wherein the outputs are unlocked with a pre-image, then it opens itself up to men-in-the-middle attacks. In case of an on-chain settlement, when the transaction is broadcasted containing this input which is spent only with a pre-image, then the the node relaying or the one mining, will know this preimage and just change the outputs of the transaction to the ones paying themselves. That is the reason, we use signature verification, so that the person spending the input signs the entire transaction so none of it can be modified.

If you are wondering, then how HTLCs are offered for lightning payments, it is not that simple as a simple private key. Below is a script that shows the commitment that the other party signs to a transaction I am holding when I am offering the HTLC.

```
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # To local node via HTLC-timeout transaction (timelocked).
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # To remote node with preimage.
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

```

If we have all outputs constructed in this way, then the transaction size will be unnecessarily large, and also will have inefficient key management as I mentioned in the previous section.

> **Comments:**
> **username_0**: But if I understand correctly the `revocationprivkey` would also have to be stored for every transaction, since `per_commitment_secret` would have to be regenerated for every new transaction?  
> **username_2**: @username_0 not necessarily; the keys can be calculated from a compact representation. For key generation, you just generate a seed, and then use an index to bit flip and hash the result. For storage, only one secret for each unique prefix need be saved; in effect, the number of trailing 0s is counted, and this determines where in the storage array the secret is stored. You can read more key storage in BOLT #3 here: https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#efficient-per-commitment-secret-storage  

---

