Lightning Network Basics — Part 4

I will present the basic technical details of the Lightning Network over the course of several articles.

Lightning Network Basics — Part 3

In this article, Commitment Transaction is explained.

Summary

Basically, the Lightning Network protocol is designed to work regardless of the creditworthiness of the counterparty, and the Commitment Transaction is a key component.

The Commitment Transaction is a transaction whose Input is the channel Output of the Funding Transaction that is published to the blockchain when the channel is opened, and is re-created between the LN nodes each time the channel balance is updated.

This transaction is only published when the channel is closed without agreement between the channel nodes, although it is re-created. This method of closing is sometimes called “force close” because it can be done regardless of the channel peer status(online / offline).

Transfers on the Lightning Network are performed in such a way that the channel can be closed and the balance reclaimed in Bitcoin at any time by publishing a Commitment Transaction to the blockchain. The Commitment Transaction specification is in BOLT #3.

Structure

The Input of a Commitment Transaction is the Output to the Funding Transaction channel. There are various types of Outputs of Commitment Transacion.

to_local and to_remote

Since the balance of the channel is refunded, each end of the channel becomes an Output. However, because of Bitcoin’s Dust Limit, if the Output is less than the Dust Limit, it will be added to the transaction fee without an additional Output.

If Alice and Bob are at both ends of the channel, the Commitment Transaction that Alice can disclose and the Commitment Transaction that Bob can disclose are different.

The output of a Commitment Transaction can be either to_local (to you who published the transaction) or to_remote (to the peer node), and while the balance is transferred to to_remote relatively quickly, the balance of the to_local transaction cannot be retrieved until much later(This time is specified by the peer node when the channel is opened).

The reason for the asymmetry between local and remote is that the Commitment Transaction is reconstructed each time when the balance changes, as shown in the previous article.

If you publish a Commitment Transaction and it is immediately forwarded to you as well, you might exploit an opportunity when the other node is offline to deploy a convenient Commitment Transaction for yourself, such as a transaction before it is forwarded. If this is the case, the other node may take advantage of the fact that the node is offline.

to_local is a transfer to a script, and local will not be able to receive it without approval of the agreed number of blocks.
And if the published Commitment Transaction is not up-to-date, the script allows the remote to transfer the past Commitment Transaction Output to another address without waiting for the block count(but only if the local has not reverted).

to_local Output

Here is the script for to_local Output.

OP_IF
    # Penalty transaction
    <revocationpubkey>
OP_ELSE
    `to_self_delay`
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

If the <revocationprivkey>is known, it can be solved using a signature.
This is used to reclaim an old Commitment Transaction as a penalty from the to_localOutput published by the peer node(Since it is a violation in the Lightning Network to publish an old Commitment Transaction, there is a penalty to prevent them from even thinking about publishing it).

<revocation_sig> 1

This is what happens if you solve it after it is Time Locked. This is a normal refund.

<local_delayedsig> <>

HTLC

The Lightning Network uses the Hashed Time Lock Contract (HTLC), which appears in BIP-68 and BIP-112, among others.
The Bitcoin script OP_CHECKSEQUENCEVERIFY (hereafter OP_CSV) cannot be solved and transferred to another Bitcoin address until the transaction has reached its approved time (mainly block count).

If the original data of the hash value embedded in the Bitcoin script is known, the script is solved immediately; if not, it is time-locked until the time specified in OP_CSV.

Offered HTLC Output and Receved HTLC Output

Lightning Network transfers express the amount being transferred in HTLC. The status is also the Output of the Commitment Transaction.

When transferring amounts from Alice to Bob, add Offered HTLC Output to the Commitment Transaction that Alice can publish.

• If you know the original data (PreImage) of the hash (Payment Hash) of the HTLC, you can immediately solve the script. Usually, the final destination (here Bob) has the original data (PreImage) of the hash.
• Once the Time Lock period has passed, the HTLC-Timeout Transaction can be published and the script can be unscripted. This is used when the transaction is not received within the time period and times out and the originator (in this case, Alice) has to retrieve it.

Bitcoin script stack : redeem from Offered HTLC Output using PreImage

Add Received HTLC Output to Commitment Transaction that Bob can publish.

• The script can be solved by publishing the HTLC-Success Transaction. Usually, the transferee who knows the PreImage (in this case, Bob) will publish it.
• Once the time lock period has expired, the source (in this case, Alice) can reclaim it.

Bitcoin script stack : redeem from Received HTLC Output using PreImage

Anchor outputs

Commitment Transaction is published to the blockchain in most cases when the other node is no longer available, but the transaction may take longer to approve due to a high feerate between the last update and publication.

Adds Output for Bitcoin’s CPFP (child-pays-for-parent) by specifying option_anchor_outputs when opening a channel for Lightnitng Network. Other scripts will vary slightly, but the basic content is the same.

In conclusion

This article introduced Commitment Transaction.

Next article

Lightning Network Basics — Part 5

Nayuta Inc.

Nayuta