lightning network – How the is the refund transaction in Asymmetric Revocable Commitments constructed?

When you first create the channel, the first thing Hitesh and Irene do is sign the initial commitments, which assigns the initial balance to themselves. This is what is called the refund, because if one of the parties decide not to proceed, the coins returns to the owners. This transaction is a normal commitment transaction but is created because if not, the funds could be locked forever on a multisig if one of the parties of the channel disappears!

First two examples

The first two examples are commitment transactions created. Each user creates one commitment transaction with two outputs. In these, both Hitesh and Irene have two outputs:

1. The first output is a payment to the other person of the initial
   balance (5 BTC).
2. The second output is a payment to the same person making the
   commitment but with a locktime of 1000 blocks. (The locktime goes there, not in the refund!)
   This commitment is not broadcasted, each one of the parties has his own version. Each one of the parties at any moment can sign it and broadcast it. In that case the other person would receive the 5 BTC instantly and the person responsible for the broadcast will have to wait 1000 blocks.

Note that this commitment transactions are incomplete as the penalty mechanism is missing in case some party tries to cheat. In the book they show this uncompleted version to give an idea of how it looks

Third example

This last example shows how to create a real commitment transaction with the penalty mechanism included.

It adds a condition which allows a user to retrieve the funds of the second output if it has the revocation private key. The revocation key is a key which both parties can calculate the public key, but they can only get half of the private key. So they only have half of the private key. If at any moment, one of the two users has the two halfs of the private key, it could claim the funds in the second output.

If the channel state is updated and a new commitment transaction is created, they exchange their half of the revocation private key. This gives them the security that if the other person cheats and broadcast an old commitment transaction, the victim will be able to claim the other person the funds as a punishment.

Imagine Hitesh tries to cheat; since Irene can claim his 5 BTC instantly (output 1), and Hitesh has to wait 1000 blocks to get the 5 BTC, Irene can claim Hitesh coins as she has the full revocation private key (this is the new condition we added in the 3rd example).

Note that if Irene doesn’t claim the funds before 1000 blocks Hitesh will be able to proceed and claim himself the coins.

Summary

So as a summary, commitment transactions look like the third example as the penalty mechanism is needed. Refund transaction is just the first commitment transaction that just returns the funds to the users. The penalty mechanism is also needed there because if you don’t add it you could cheat and steal coins by broadcasting the refund transaction in the future when the channel state has advanced.