In previous articles, we have extensively discussed the basics of the Lightning network, including payment channels and associated HTMLs.

To date, the user-friendliness of the Lightning network leaves much to be desired. The Lightning implementations are all still in the beta phase, in which it is especially necessary to iron out all the wrinkles for a smooth user experience. During this process, new ideas are put forward to achieve this.

Watchtowers

One of the new ideas is watchtowers. To find out the usefulness of watchtowers, it is first necessary to understand how the penalty mechanism within Lightning works, which ensures that people remain fair during the maintenance of a payment channel.

Where payment channels work with keeping track of the state – the mutually agreed balance – of the channels, the penalty mechanism ensures that an older state of the balance cannot be broadcast without consequences. This is what Alice might want to do when she has made a payment to Bob. Alice can get her pre-payment balance back by using the old state of the payment channel. When one sends an older state to the bitcoin network, the penalty mechanism detects this and ensures that the dishonest party must transfer the entire balance to the other party, as a penalty. As a result, dishonest behavior results in loss of credits.

To detect any dishonest transactions, and thus prevent loss of funds, there must be a Lightning node online that can monitor this. Unfortunately, such a node also comes with all the extra data from the blockchain. It is therefore virtually impossible to do this completely sovereignly on, for example, a mobile phone. In addition to the data storage of many gigabytes, you also need to be permanently connected to the network. Watchtowers come to the rescue here.

Watchtowers keep an eye on the transactions for you. Using a third party for transaction validation is often not desirable. The aim is to be able to consult a large number of independent and self-selected watchtowers. These watchtowers will then report when something is wrong. This prevents an older state of a payment channel from being used by the other party, which could result in a loss of balance.

The broadcasting of an old state can also be done by your own wallet, in addition to a malicious counterparty. This can occur when the own wallet is not aware of the latest state of the payment channel. For example, when a wallet needs to be restored without all current data being in the wallet. As a result, the wallet may broadcast an older state without malicious intent, triggering the penalty mechanism, resulting in a loss of funds.

eltoo

Eltoo is a change to the punishment mechanism proposed by Christian Decker and Rusty Russell. Where until now a fine has been applied for deliberately or unknowingly broadcasting an old state, eltoo seeks the solution in only enabling the broadcasting of the latest state. So this avoids the need to impose a penalty for broadcasting an old state. The biggest advantage of this is that the problem outlined above, with an out-of-date wallet, will no longer occur. For example, a Lightning user without malicious intent will not lose credits by broadcasting an old state.

The image above shows an example of the eltoo protocol. It shows how an intermediate statement can be skipped by linking a later transaction statement to an earlier transaction. Linking is also possible to the initial setup transaction. Only the last settlement transaction can be confirmed on the Bitcoin blockchain in this way.

To get eltoo functional, a small adjustment has to be made to the bitcoin protocol. SIGHASH_NOINPUT should be introduced for the digital signatures of bitcoin transactions. This change can be implemented through a soft fork, if there is agreement on how this change can best be implemented.

splicing

To date, paying via Lightning is not possible at, for example, a webshop that only accepts direct bitcoin payments, without first closing the entire payment channel. Splicing makes it possible to make an on-chain transaction directly from a Lightning channel, without having to close the payment channel for this. This makes securing bitcoins in a payment channel more flexible because, in addition to Lightning payments, it also retains the functionality of an on-chain transaction.

This is also possible vice versa; increasing the balance of a payment channel with an on-chain bitcoin transaction, without having to close an old channel and open a new one. Splicing makes use of changing the balance of the transaction that opened the channel.

Atomic Multipath Payments (AMP)

Lightning uses a routing mechanism where bitcoins can be sent through multiple hubs. A hub can only transfer the amount of bitcoins that are in the wallet of the hub itself. The Lightning network facilitates fast and small transactions at minimal costs. Because a Lightning wallet can be seen as a wallet with change for the daily coffee, it is difficult to send larger amounts. This is because each hub must have sufficient balance to get the bitcoins to the beneficiary if no direct payment channel has been established.

AMP makes it possible to split a larger payment into smaller parts and send it to the beneficiary via multiple routes, after which the recipient receives the payment as one. This way, a large amount can still be forwarded through smaller hubs.