Thunder Network Update: New On-Chain Settlement (Refund) Feature Debuts

A few months ago, we released the alpha version of Thunder Network. We explained at the time that most transactions in Thunder Network are not conducted on the Bitcoin blockchain, and only the small number of transactions that need to be recorded on the blockchain are handled properly for Thunder Network to work properly. In layman's terms: a contract that cannot be enforced in a court of law is invalid. The same principle applies to Thunder payments - users need to have confidence that the payment sent to the "court" (the Bitcoin blockchain) is valid.

At the beginning, we launched the layer-2 payment protocol - dual-tx. Dual-tx can bring many advantages, but it is much more difficult to implement updates and upgrades than we thought.

How dual-tx makes Thunder Network more convenient to use

In the current protocol layer, a refund takes more than a month, provided that you are offline for no more than one day during this period. If you want to go out and play for two weeks, the refund time may be extended to about a year. We hope to shorten the refund time as much as possible so that the recipient will not delay further.

Dual-tx adds a second protocol layer between broadcasting settlement and requesting payment, so that the process of requesting payment is separated from the process of waiting for delayed revocation. If the recipient wants to cancel the transaction, he must request the second-tx output after the delayed revocation expires and broadcast the second transaction at the same time. If any party to the transaction commits fraud, the other party can even get the funds back in the second protocol layer. This transaction in the second protocol layer functions like a safety net. Note: The second protocol layer is only required if you want to broadcast the output request of the channel transaction. Any party to the transaction has the right to refund the transaction directly from your transaction channel at any time.

This approach shortens payment time to 1 day and refund delay cancellation time to two weeks, greatly improving protocol performance.

Here are the details about this update as shared by our engineer Mats Jerratsch.

Processing transaction settlement

To make this process easier to understand, I will divide it into 3 points.

First, we will track and monitor the transaction blocks of the channel anchor. Once a similar transaction is found, we will call ChainSettlementHelper.onChannelTransaction(..) to analyze and confirm whether its source and specific transaction information are consistent with our records (if they are not consistent, there is a suspicion of fraud). Then we create a corresponding ChannelSettlement object for each payment. In order to output normally, we will track the status of each payment. After this process is completed, all ChannelSettlement will be stored in the database.

Secondly, ChannelSettlements will change with each block information update. The transaction party's funds, payment requests and updates will be stored so that users can initiate payments again. You can check it using ChainSettlementHelper.onBlockSave(..) .

Third, Bitcoin transactions are created using ChainSettlementHelper.onBlockAction(..) and users need to broadcast based on the following flags:

1. ourTx — Are we broadcasting the channel on the blockchain or does the other party want on-chain settlement?

2. Cheated - Is this channel transaction the latest one or is it a fraud?

3. Sending——Are we the payment initiator or receiver?

4. secondTx — Have we seen the second transaction payment in the block?
   

Typical Cases

A typical example is this: I made a payment to Bob, but I want to refund it, but Bob is not online. Since the refund time agreed upon by Bob and I is approaching, I have to make a decision myself. Should I ignore the payment or keep the payment channel open? From the situation in this case, it is better to close the payment channel.

We only broadcast the last channel transaction. Once we find it in the block, onChannelTransaction(..) will store the ChannelSettlement object in the database accordingly. The onBlockAction(..) function will include some payment secret in the dual-tx, which is necessary so that the payment does not time out.

The transaction will then arrive in the next block, so onBlockSave(..) can update the ChannelSettlement object. But the information cannot be stored until after the delayed revocation time, which takes about a week. We have to wait for 1008 blocks. The transaction created by the ChainSettlementHelper.onBlockAction(..) function will eventually make the refund reach our wallet.

When one of the parties in a transaction is suspected of fraud, we can usually apply for all channel transaction outputs. To achieve this goal, we need to retrieve the hash that was revoked in the transaction. Unless the data is lost, we can retrieve the hash from the database, or use some more advanced mechanisms such as shachain calculations to achieve the goal. However, if a transaction participant decides to broadcast a second-tx payment, he may lose some funds (handling fees).

For those who have already experienced fraud, this new feature is not suitable for the time being. It is definitely not used much and I don't want to encourage fraud. Any suggestions for improvement are welcome.

Perfect code, but hopefully never executed

I hope we don't have to worry about transaction fraud anymore, so I hope this code will never be executed. But I still have to say that this code has been rigorously tested in many cases, and the Bitcoin script can work normally when the code is executed. However, code that has not been tested is not perfect, so we welcome any improvements and suggestions.