HTLCs and commitment transactions

2

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?

spacemonkey

Posted 2019-06-19T14:09:02.310

Reputation: 137

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 – 2019-06-19T14:25:19.103

Hi @RenePickhardt, I have added some additional info, hope this helps :) – spacemonkey – 2019-06-19T14:43:45.800

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 – 2019-06-19T15:04:25.077

Answers

0

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.

Ugam Kamat

Posted 2019-06-19T14:09:02.310

Reputation: 5 180

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 – 2019-06-19T16:13:29.720

1

@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 – 2019-06-19T16:56:41.600

Asked: 2019-06-19T14:09:02.310

Viewed: 59 times

Active: 2019-06-19T17:09:49.937