Lightning network nodes can support fast and timely IoT micropayments, and the operating costs are very low.
Original title: “Introduction | With Lightning Network Gateway, Instantly Complete Micropayments”
Written by: Omer Shlomovits
Imagine you drive to a field to attend an important meeting, and you will pass through three toll booths along the way. Then you have to pay tolls, don’t you have to slow down the car and waste some time? This created the need for an “automatic payment system”.
Relying on device-to-device communication (D2D) to complete atomic payment without human intervention is an ideal solution to this problem. Although it is possible to associate these devices with traditional payment systems (such as credit cards), this introduces a third party who may pass on management costs to you and even collect your privacy. In this way, cryptocurrency can create a more convenient payment system. Therefore, the combination of IoT (Internet of Things) and cryptocurrencies (such as Bitcoin, Ethereum) can solve these problems.
With the concept of a decentralized ledger, Bitcoin has become a disruptive payment system, but for payment scenarios, it has some major flaws, such as high handling fees and long transaction confirmation times.
The Lightning Network (LN) has solved these problems with a bold approach-off-chain payment. With this progress, the use of Bitcoin for micropayments is also promising, and it can also be accepted by many IoT applications. However, hosting Lightning Network and Bitcoin nodes on IoT devices is not feasible due to their storage, memory, and processing overhead.
Since the advent of the Lightning Network, it has more than 20,000 nodes. IoT devices have very limited computing, communication and storage capabilities; therefore, it is impossible to install lightning nodes on most low-profile IoT devices. Specifically, using the Lightning Network requires you to run a Lightning node and a Bitcoin full node, which together require more than 340 GB of storage space. To participate in the verification of Bitcoin blocks, a reliable Internet connection and relatively high computing power are also essential.
Considering all these factors, we need a lightweight solution. We propose a protocol based on threshold cryptography. A trusted Lightning Network gateway is responsible for hosting complete Lightning Network nodes and Bitcoin nodes, so that IoT devices can initiate Lightning Network operations through this gateway.
You can also incentivize the LN gateway to provide this service by paying a commission.
Our proposed agreement has the following characteristics:
Lightning Network
Our protocol will use the Lightning Network. The Lightning Network was a concept proposed in 2015, and it was quickly implemented on Bitcoin by Lightning Labs and other groups. It is a peer-to-peer layer 2 network on top of the Bitcoin blockchain network.
The Lightning Network is committed to solving the scalability problem of Bitcoin. Using Bitcoin’s smart contract function, Lightning Network allows users to open secure payment channels, enjoy instant and cheap Bitcoin transfers, and realize multi-hop indirect payments in the network.
Since its inception, there has been a considerable increase in the number of users using the Lightning Network. The Lightning Network now has a total of 59,192 channels, with 1986.06 btc retained.
Let’s use an example to make the Lightning Network more clear:
Alice wants to pay Bob, so she opens a Lightning Network payment channel with Bob. In this payment channel, funds can flow in both directions between Alice and Bob without submitting the transaction to the Bitcoin blockchain. In other words, the transaction takes place off-chain.
Figure 1. The life cycle of a Lightning Network channel
As can be seen from Figure 1, an important cornerstone of the Lightning Network is a commitment transaction. The commitment transaction has three outputs.
The three outputs of the committed transaction issued by Alice are generally:
Assign Alice her current balance in the channel, but with a time lock, it will take a while to use
Assign Bob the current balance in the channel, which is available immediately
Payment contract (essentially HTLC, hash time lock contract)
Translator’s Note: Commitment transactions can be submitted to the Bitcoin blockchain at any time to make the fund distribution effect true. Therefore, once the commitment transaction is exchanged, it means that the balance of both parties is updated and the payment is completed; as long as no party broadcasts the commitment transaction to In the network, the channel is always open, and both parties can transfer almost unlimited times.
Lightning Network Technology Fundamentals (BOLT)
For our agreement, we modified the Lightning Network Technology Foundation #2 of the Lightning Network. The technical basis of the Lightning Network is the peer-to-peer protocol used by the Lightning Network to manage the channel, which is used to implement secure Bitcoin off-chain payments.
BOLT #2 has three stages:
Channel establishment
Normal operation of the channel
Channel closed
Threshold Cryptography
Our main innovation is to add threshold cryptography to the Lightning Network.
Sharing secrets in real life are very common, but we have to borrow them from the digital world.
“Threshold cryptography” is a subset of Secure Multiparty Computation, which deals with cryptographic operations involving more than one party.
In the world of cryptocurrency, the theft of a private key (which should be a secret value) will result in a loss of funds. Therefore, people have proposed the idea of splitting the key among multiple parties. In a threshold scheme, the key is divided among multiple parties, and a threshold is predefined. If the number of participants is less than this threshold, no information about the key can be known anyway.
In order to use the Lightning Network on IoT devices without having to bear all the memory burden, we need to use threshold cryptography.
This is also achievable because we have separated the Lightning Network nodes, and IoT devices only need to participate in the key cryptography part.
Doing so can speed up our development process, make the entire system easier to run, and save costs.
System mode
Figure 2. Schematic diagram of the system pattern
Our system has four main parts: (1) IoT devices; (2) Lightning network gateway; (3) Bridging lightning network nodes; (4) Target lightning network nodes.
Other intermediaries include: (1) Threshold client; (2) IoT device gateway; (3) Bitcoin core Lightning Network node of Lightning Network gateway; (4) Threshold server.
Some assumptions:
IoT devices can be connected to the Internet through a gateway.
IoT devices and Lightning Network gateways will not be dropped during the payment process.
IoT devices can be offline for the rest of the time.
protocol
Suppose an IoT device now wants to pay a target Lightning Network node (such as paying tolls)
Starting from the IoT gateway, the device contacts _Lightning Network Gateway_, and the gateway manages Lightning Network nodes, Bitcoin nodes and threshold servers
Whenever an IoT device initiates a request, the Lightning Network Gateway opens the channel to bridge the Lightning node to connect to the target network node
Bridged network nodes can charge routing fees to the Lightning Network gateway that initiates the payment
Payments for IoT devices are routed to the specified target node through the bridge node
Now, the operation of threshold cryptography runs between the IoT device and the Lightning Network gateway, so only the Lightning Network gateway needs to run this improved protocol. The rest of the system can run the original BOLT protocol.
Safety analysis
Here, we assume that our system will face three threats: conspiracy attacks, IoT devices and lightning gateway conspiracy and blackmail attacks.
Conspiracy to attack
1. The Lightning Gateway colludes with the bridge node. In our system, payment is always sent from the IoT device to the target lightning node, which in turn will always increase the balance of the bridge node in the channel. Therefore, the old channel state balance of the bridge node will always be lower than the latest state, so such collusion will not occur. Our set of agreements is currently limited to one-way payments. Realizing two-way payments for IoT devices is the future work.
Now, suppose the Lightning Gateway wants to broadcast the old state to the blockchain network. Only when a certain old state of the Lightning Gateway has more funds than the current state can it be beneficial. However, this is also impossible, because the Lightning Gateway charges for every payment made by the IoT device, and its balance is always rising. In addition, the old state balance of the bridge node must also be low. Therefore, both of them have relatively low balances in the old state, and the collusion will not benefit.
(Translator’s Note: Adding some background may help readers understand why these threats need to be analyzed and how these threats are dealt with: In this system, IoT devices and gateways use a threshold private key to open a channel with the bridge node (multi-signature Contract), but each committed transaction has an output to allocate funds to the addresses controlled by the IoT device and the gateway, instead of assigning the funds to the threshold private key; therefore, the channel can ensure that the balance of the gateway and the bridge node is always increasing. For details, see the complete paper attached at the end of the article.)
2. Collusion between IoT devices and Lightning Gateway: Because the funds in the IoT device’s channel always fall as payment occurs, it is easy to collude with the Lightning Gateway and broadcast an outdated status to the network.
If the bridge node does not want to lose funds, it cannot go offline at other times. Therefore, this collusion is not unique to our agreement, but a common problem with the Lightning Network.
Theft of funds from IoT devices
The Lightning Gateway can steal funds promised by IoT devices through the following methods:
Send them to other Lightning Network nodes
Broadcast the old state to the network
Collusion with other Lightning Network nodes
If we use the original signature mechanism of the Lightning Network, the Lightning Gateway can take away the funds of the IoT device in the channel without the need for a signature from the IoT device. Our proposed modification-the threshold scheme used in the commitment transaction of the Lightning Gateway (2-2)-is to protect IoT devices from losing funds. IoT devices, because the channel is opened using the private key they calculated together).
Blackmail attack
This attack is a situation where the Lightning Gateway deviates from the protocol description. For example, the gateway can tell the IoT device, “Give me how many bitcoins, or I won’t close the channel for you”, or “From now on, you have to accept a 10% service rate. If it’s better, I won’t give it to you.” Served”.
At this time, the best way for IoT devices is to refuse blackmail and consume them. Then, the Lightning Gateway will hold the funds of the IoT device and delay as much as possible. This is an endless loop, and both sides are exhausted.
The best practice for LN gateways is to continue to serve IoT devices and charge service fees.
Application and experiment
The application scenarios of our agreement include electric vehicle charging piles, sensor data sales and parking lot charging systems. Let’s take the toll station at the beginning as an example, because we have also tested it on the spot.
Real-time response is the most critical for toll booths, because the ideal state is that the car does not need to stop when passing through the toll booth, and the payment can be completed by using (for example) the wireless network.
Whenever a car enters the wireless coverage area of a toll station, it initiates a payment request to the lightning gateway of the toll station through the IoT gateway. The lightning gateway immediately sends the requested payment amount to the lightning node of the charging company. After the payment is completed, a message indicating “payment successful” is returned to the vehicle through the IoT gateway.
For this system to work in reality, the entire payment process must be completed before the car leaves the wireless network coverage of the toll booth.
Because the payment only takes 4.12 seconds, the car can complete the payment in time.
As for the cost, we assume that a car has to pay tolls twice a day. Assuming that the car has been opened in advance, the only cost of using this set of services is the service fee charged by the lightning gateway for each payment. Although this rate is determined by the gateway, we assume that the service fee amount is 5% of the actual toll fee. If you need to pay a toll of US$0.75 for each pass, then the handling fee for each payment is US$0.0375, and the monthly service fee is only US$2.5 (0.0375*60).
Considering the convenience of instantaneous payment of tolls, it shouldn’t be a big deal to spend an extra $2.50 per month. In fact, credit card companies charge similar or even more.
in conclusion
Our evaluation results show that Lightning Network nodes can support fast and timely IoT micropayments, and operating costs are very low.
The purpose of this research is to enable IoT devices with limited resources to interact with the Lightning Network (which is generally impossible) and conduct micropayments with other users.
As far as we know, this is the first work to implement threshold cryptography in the Lightning Network.
So, you can enjoy the trip and arrive in time without worrying about paying tolls!
Our protocol can also be used in many other IoT micropayment applications (that is, not limited to toll payment).
Our achievement is also a milestone in the development of a general framework for the Lightning Network of Threshold Cryptography. To understand all the details of the entire program, please see our paper.
Hope you have gained something!
Source link: zengo.com
