The principle and importance of lightning network "justice trading"

The third report on lightning network released by Bitmex Research has attracted a lot of attention. The article introduces a mechanism to punish non-honest parties and prevent them from stealing funds. This mechanism is called "just trade" ( Justice Transaction).

In its report, Bitmex mentioned that it detected a total of 241 "just transactions" involving a total of 2.22 BTCs.

Many readers only pay attention to the results after seeing the relevant reports, but do not consider why the lightning network needs this mechanism and its specific principles.

In fact, “just trade” is the implementation version of the game mechanism mentioned in Section 3.1.4 of the Lightning Network White Paper . Through this mechanism, all parties who maliciously violate the agreement will lose all funds in the channel.

• Can Libra win Bitcoin? How to break the high buy low sell spell? Everything you want to know here
• Libra vs. US Congress, a few questions about gunpowder
• Report: 96% of BSV transactions are from this weather app

"Justice Trading" Overview

The so-called "just trade" is a stimulus that aims to prevent non-honesty nodes from stealing funds by broadcasting an old channel state.

It is worth noting that under this design, when thieves attempt to steal funds from the lightning network, if they are caught, they will not only lose the funds they are trying to steal, but also lose all the funds in the relevant channels. This "punishment" measure is expected to serve as a deterrent and is therefore called "justice."

Suppose a scenario like this:

There is a never-ending deal between Alice and Bob. If a lightning network channel is opened between them, they can send BTC funds to each other in proportion to the input value. For the sake of convenience, we assume that they have put 1 million Cong (0.01 BTC).

If both Alice and Bob keep the nodes online while the transaction is being processed, then everything will be normal. This means that whenever either party decides to close the channel, they will have a scenario that both parties agree. In this scenario, the amount returned on the main chain will follow the exact history of the transaction. If they both close the channel, this may be a synergy. And if only one of them is turned off and the closed time established is passed without the other party acting, it may be non-cooperative. However, this is the ideal state for no one to be a victim of theft.

If Alice wants to steal Bob's funds, she must try to close the channel in a non-cooperative way (with the other party without knowing it) and steal it when the other party is offline. If these conditions are met, Alice will broadcast an old channel status and expect Bob not to align the recording online for the specified time (usually 24 hours).

If Alice's attempt is successful, she will irrevocably steal funds that were illegally requested from Bob. But if Bob returns within the time limit, Alice will be penalized for the 0.1 BTC she placed in the channel.

Four lightning network channel closure schemes

In general, turning on a lightning network channel is much simpler than closing a channel because there is only one way to open a lightning network channel. On the other hand, when evaluating channel closures, we need to consider four different scenarios, as outlined in the decision tree below.

The first type of closure: cooperative closure

This is the most common scenario where a collaborative shutdown occurs when an honest node initiates a channel shutdown and the node at the other end of the channel is online and communicating.

Funds are allocated to the onchain wallets of the parties based on the latest channel status.

Cooperative closure only requires an onchain transaction. The input is cashed using a "normal" 2 of 2 multi-tap script and sent to both outputs, each of which belongs to the relevant party, and the balance is based on the latest channel status.

This transaction is difficult to identify as a lightning network transaction, so it is the most intimate of the four channel closure types.

Example close: https://www.blockstream.info/tx/92370444373ab37c998999e0df0416c460166aa4845a940b66322c4934c6984f

The second type of closure: non-cooperative non-breach closure

Non-cooperative non-default closure occurs when an honest node initiates a shutdown without directly communicating with the node at the other end of the tunnel.

Funds are allocated to the onchain wallets of the parties based on the latest channel status.

The third type of closure: non-cooperative breach non-justice closure

Non-cooperative default injustice closure occurs when a dishonest node attempts to steal funds from a node at the other end of the channel by broadcasting an earlier channel state, thereby initiating channel closure.

Non-shutdown nodes do not check the network (usually 24 hours) during the lockout period, nor do they broadcast fair transactions, so the theft can be successful.

The second and third closed scenarios mentioned above require two onchain transactions.

First, use a 2 of 2 multi-sign witness to redeem the funds and send them to the two outputs. Nodes that have not initiated the shutdown will allocate funds based on what the channel closure party said can be attributed to them, while another fund Will be sent to the output, which can be redeemed using the OP_IF or OP_ELSE script.

In the second transaction, the funds sent to the OP_IF script, which are closed by the originating channel, are claimed using the OP_ELSE branch of the Bitcoin script.
Example Close: Transaction 1 (https://www.blockstream.info/tx/0134992ff298d42835a1c47dc41cf7be8dbb91b3122e6391728e555046143844?expand)
Transaction 2 (https://www.blockstream.info/tx/a08e6620d21b8f451c63dfe8d0164f0ba1b2dc781ea163c7990634747b57282c?expand)(OP_ELSE)

The fourth type of closure: non-cooperative breach justice closure

When a dishonest node initiates a channel shutdown without directly communicating with a node on the other side of the channel, a non-cooperative default is closed.

The non-shutdown node checks the network during the lockout period and creates a fair transaction, which causes the theft operation to fail.

Potential thieves are punished and all funds flow to honest non-closers.

In a just trading scenario, two onchain transactions are required.

In the first transaction, a 2 of 2 multi-signitis is used to redeem the funds and send them to the two outputs. The nodes that have not initiated the shutdown will allocate funds according to the content that the channel closure party said attributable to them. Another money will be sent to the output, which can be redeemed using the OP_IF or OP_ELSE script.

In the second transaction, the honest node that did not initiate the shutdown uses the OP_IF branch to claim all funds sent to the OP_IF script.

This is the easiest to reveal of the three channel closure types and provides the lowest level of privacy.

Example Close: Transaction 1 (https://blockstream.info/tx/5cc28d4a2deeb4e6079c649645e36a1e2813605f65fdea242afb70d7677c1e03?expand)
Transaction 2 (https://blockstream.info/tx/c5597bbe1f56ea72ae4b6e2835d69c1767c3ce1317da5352aa14dad8ed22df34?expand)(OP_IF)

Bitmex manually created a justice transaction using the following steps:

1. A new Lightning Network Node (LND) with the alias "BitMEXThief" is created, and another normal node is used to open a $50 (400,000 Cong) channel;
2. Close this BitMEXThief node and back up the .lnd directory;
3. Restart the BitMEXThief node and pay the normal node a $25 (200,000 Cong) lightning deal. This channel is now balanced, with $25 in each direction.
4. Close this BitMEXThief node again;
5. Close the normal lightning network node (preventing it from broadcasting the latest channel status to the thief node);
6. Restore the "BitMEXThief" node to the state before the channel rebalance, that is, the state in step 2;
7. At the recovered "BitMEXThief" node, try to close the channel in its early state and ask the BitMEXThief node's chain purse for the full amount of $50 (400,000 Cong);
8. Restart the normal lightning network node, then the node automatically detects the attempted theft and broadcasts "just trade", sending the full amount of $50 (minus the fee) to its OnChain wallet. That would be a punishment for the thief because he lost all the funds in the passage. Note that the thief attempted to steal $25, but in the end lost $50.

The above experiment happened successfully and provided a guarantee about the lightning network. If you try to steal, you will be punished.

Justice Trading Network Data

After building their own justice transactions, Bitmex Research studied the characteristics of such transactions and searched for other justice transactions on the Bitcoin blockchain. They confirmed 241 such transactions, the earliest of which date back to December 2017.

(Source: BitMEX Research)

(Source: BitMEX Research)

Of the 241 fair trades, many may not be directed at dishonesty. For example, there may be users testing this mechanism where the same user has two problematic lightning network nodes. For example, in these 241 fair trades, there are 5 transactions of BitMEX Research (there are no victims in the transaction, because the nodes and funds are BitMEX's own).

in conclusion

In order for the lightning network to be a reliable and scalable payment system, there must be a mechanism to effectively prevent theft, and justice trading is such a mechanism. As for the optimal rate of justice transactions, this is difficult to determine. If it is too high, it indicates that the theft is still relatively easy, and the threat may not be enough. If it is too low, it may mean that no one is trying to steal, which increases the risk that users will not monitor their channels and poses a security risk for future large-scale theft.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!