Blockchain, the bitcoin-centric startup, recently offered an update on its Thunder Network on-chain settlement, having released the alpha version in May. Blockchain released the alpha version of its Thunder Network as a payments channel to be the first usable implementation of the Lightning network for…
Blockchain, the bitcoin-centric startup, recently offered an update on its Thunder Network on-chain settlement, having released the alpha version in May.
Blockchain released the alpha version of its Thunder Network as a payments channel to be the first usable implementation of the Lightning network for off-chain bitcoin payments that settles back to the main bitcoin blockchain, CCN previously reported. The payment technology prototype is described by Blockchain as a “way to send money ‘off-chain’ to other parties in a trustless manner based on the Lightning network.”
Blockchain claims Thunder has the potential to facilitate secure, trustless and instant payments. It can unleash the power of micro-transactions to allow the bitcoin network to handle heavy loads and to increase user privacy.
In its recent update, Blockchain noted in a blog that Thunder payments process without touching the bitcoin blockchain, provided those few that make it into the blockchain get handled correctly. Users must be assured those payments that make it into the blockchain are valid.
Thunder uses a two-layer payment approach called dual-tx. Deploying dual-tx has proven more difficult than expected.
In existing implementations, refunds can take more than a month. The user, however, cannot stay offline for more than a day. Take a two-week vacation, and the refund can take more than a year.
Dual-tx adds a second layer between claiming a payment and broadcasting the settlement, allowing clear separation of the process of claiming a payment from waiting out the delay revocation. Should the receiver seek to redeem a payment, he must broadcast the second transaction, allowing them to claim the output of the second-tx following the revocation delay.
Should the user cheat, the counterparty can claim the funds even from the second layer. The second transaction serves as a safety net. Going through the two layers is necessary only if the user wants to claim the outputs of a broadcasted channel transaction. The other party can refund or redeem a payment directly from the user’s channel.
The approach permits a 1-day payment window and a 2-week revocation delay, improving on the existing deployments.
Mats Jerratsch, a Blockchain engineer, explained the Blockchain solution that allows for a more convenient application.
The user first monitors incoming blocks for transactions spending the channel’s anchor. The ChainSettlementHelper.onChannelTransaction(..) can analyze the transaction, identify its origin and confirm the transaction matches the version on file. A ChannelSettlement object is created for each payment and for the output to be able to track the individual states. All ChannelSettlements are saved in the database.
ChannelSettlements update with the formation that is found in each block there on. Counterparty funds, payment claims and updates are saved the next time the user needs to act upon the state. Different cases are available in ChainSettlementHelepr.onBlockSave(..).
Bitcoin transactions are created in ChainsettttlementHelper.onBLockAction(..). They are broadcast based on one of the following:
• ourTX: Did we broadcast the channel to the blockchain or did the other party wish to settle on-chain?
• cheated: Is the channel transaction the most recent, or did someone attempt to cheat?
• sending: Have we started the payment or are we the receiver?
• secondTX: Has the second transaction been seen for that payment yet in the block?
In an ordinary case, person A receives a payment from person B and person B can redeem, but they are offline. As they approach the refund time they negotiated when making the payment, person A must make a decision. Do they want to forego the payment, even though they can redeem it, or do they keep the payment channel open?
Should they keep the channel open, they broadcast the latest channel transaction. Once they find it in a block, onChannelTransaction(..) saves a ChannelSettlement object into the database. onBlockAction(..) creates the dual-tx containing the payment secret so the payment can’t time out.
The transaction will get to the next block, so onBlockSave(..) updates the ChannelSettlement object. It saves that it must wait out the revocation delay, which is one week in this case. ChainSettlemetnHelper.onBlockAction(..) creates the needed transaction to claim the funds into the wallet.
If the counterparty cheats, the user can claim all outputs of the channel transaction. They have to retrieve the revocation hash used in the transaction. It is possible to retrieve the revocation hash from the database since it will be stored, or by computation should a more advanced mechanism like a shachain be used.
The counterparty could also waste funds should he broadcast the second tx for the payment. It is still possible to claim the second tx output, but there are losses due to transaction fees.
In cases where someone cheated, the implementation does not respond with any action. It could attempt to claim the payments, but this would only work rarely and it is not encouraged.
Blockchain has done rigorous testing in Thunder to cover all payment cases and to ensure the bitcoin scripts work. But despite the best efforts, an untested code is difficult to perfect. Blockchain welcomes reviews and exploration of the code.
Featured image from Shutterstock.
Last modified: January 25, 2020 11:55 PM UTC