Lightning Network Compatability

When an SCL state change is incorporated into a Bitcoin transaction, there is no immediate requirement for this transaction to be finalised on the blockchain. Instead, its security can be assured by its involvement in a Lightning Network payment channel. Consequently, each time the Lightning channel undergoes an update, a fresh SCL state change can be included in the updated channel transaction, rendering the previous one obsolete.

Consequently, it becomes feasible to enable Lightning channels to facilitate the movement of SCL assets and facilitate payment routing across these channels, akin to standard Lightning payments. This represents a tokenised standard on the lightning network, e.g. Tokenised assets that can be transferred for as little as 0.0002$ and settled instantly.

To establish an SCL Lightning channel, the initial requirement is a funding transaction, which comprises two distinct components: (1) the allocation of Bitcoin funds to establish the multisig structure and (2) the allocation of SCL assets to transfer them to the multisig UTxO.

The Bitcoin funding serves the purpose of creating the channel's UTxO, which will serve as the repository for the assets. Notably, the Bitcoin funding doesn't necessarily need to contain a substantial number of satoshis; it simply needs to maintain a sufficient balance to ensure that all outputs resulting from the Lightning commitment transitions exceed the dust limit without requiring an economically significant amount.

Once the preliminary transaction is primed, while still pending the signature and transmission, it becomes crucial to assemble the commitment transactions, enabling unilateral channel closure for both parties. These commitment transaction structures closely mirror those of standard lightning channels, with the sole exception being incorporating an additional output housing the SCL anchor for the SCL state transition.

The SCL state transition facilitates the transfer of assets from the multisig location where the initial funding occurred to the outputs generated by the lightning commitment transaction. In this manner, the SCL state transition directly inherits all security attributes from the lightning commitment transaction in the event of a unilateral channel closure. Consequently, if Dom were to broadcast an outdated state, Paul would possess the ability to expend the output using Dom's confidential information. During this expenditure, he not only shifts the satoshis to an address exclusively under his control but also relocates the SCL assets to one of his UTxOs. This dual-layered economic deterrent for attempting theft with an obsolete state is not limited solely to the satoshis amount, which may be trivial but extends to all the SCL assets previously locked within the channel.

Conversely, if the commitment transaction broadcast by Dom was indeed the last state of the channel, Paul wouldn't be able to spend the output that triggers the punishment transaction. In this scenario, Dom will have the capability to claim both the satoshis and the SCL assets once the time-lock has expired.

Hash Time-Locked Contracts

In the passage above, we witnessed a simplification of payment channels involving just two parties. However, in reality, the Lightning Network is designed to facilitate payments involving multiple participants, and all payments inherently utilise HTLCs (Hash Time-Locked Contracts) outputs. The same principle applies to SCL channels; for each payment routed through these channels, a dedicated HTLC output is appended to the lightning commitment transaction. The HTLC output must contain a Bitcoin amount exceeding the dust limit, although its economic significance can be minimal. Simultaneously, alongside the new HTLC output, a corresponding allocation must be incorporated into the SCL state transition. This allocation directs the quantity of assets involved in the payment toward the fresh HTLC output. The party who successfully claims the HTLC output, either through possession of a secret or by waiting for a time lock expiration, can transfer both the satoshis within the output and all the assets linked to it.