HTLCs and commitment transactions

Question

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?

Answer 1

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 and saved compactly.

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.