introduction

Original link:

https://zengo.com/make-micro-payments-in-a-flash-the-power-of-lngate/

introduction

Imagine you are driving out of town to attend an important meeting, passing through three tollbooths along the way. Then if you have to pay tolls, don’t you have to slow down the car and waste some time. This creates the need for an "automatic payment system".

Atomic payments that rely on device-to-device communication (D2D) without human intervention are an ideal solution to this problem. While it is possible to link these devices to traditional payment systems such as credit cards, this introduces a third party who may pass the administrative costs on to you, or even collect your privacy. Viewed in this way, cryptocurrencies can create a more convenient payment system. Therefore, combining IoT (Internet of Things) and cryptocurrencies (such as Bitcoin, Ethereum) can solve these problems.

With the concept of decentralized ledger, Bitcoin has become a subversive payment system, but for payment scenarios, it has some major flaws, such as high handling fees and long transaction confirmation time.

The Lightning Network (LN) has solved these problems with a bold approach - off-chain payments. With this advancement, Bitcoin is also promising for micropayments and can be accepted by many IoT applications. However, hosting Lightning Network and Bitcoin nodes on IoT devices is not feasible because of their storage, memory, and processing overhead.

Since its inception, the Lightning Network has grown to over 20,000 nodes. IoT devices have very limited computing, communication, and storage capabilities; therefore, it is impossible to install a Lightning node 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 over 340 GB of storage. To participate in the validation of Bitcoin blocks, a reliable internet connection and relatively high computing power are also essential.

Taking all these factors into consideration, we needed a lightweight solution. We propose a protocol based on threshold cryptography, where a trusted Lightning Network gateway is responsible for hosting complete Lightning Network nodes and Bitcoin nodes, allowing IoT devices to initiate Lightning Network operations through this gateway.

LN gateways can also be incentivized to provide this service by paying a transaction fee.

Our proposed protocol has the following characteristics:

• Ability to make instant payments

• Can run on low-bandwidth networks

• lightning network

lightning network

Our protocol uses the Lightning Network. The Lightning Network was conceived in 2015 and 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 works to solve Bitcoin's scalability problem. Leveraging Bitcoin's smart contract capabilities, the Lightning Network allows users to open secure payment channels, enjoy instant and cheap Bitcoin transfers, and enable multi-hop indirect payments across the network.

Since its inception, the number of users using the Lightning Network has grown considerably. The Lightning Network now has a total of 59192 channels holding 1986.06 btc.

Let's use an example to explain the Lightning Network more clearly:

image description

- 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 the commitment transaction. Commitment transactions have three outputs.

The three outputs of a Commitment transaction issued by Alice are generally:

1. Assign Alice her current balance in the channel, but with a time lock, it will take a while before she can use it

2. Assign Bob his current balance in the channel, which is immediately available

3. Payment contract (essentially HTLC, hash time lock contract)

first level title

Lightning Network Technology Basics (BOLT)

For our protocol, we have modified the Lightning Network Technical Foundation #2 of the Lightning Network. The technical basis of the Lightning Network is the peer-to-peer node protocol used by the Lightning Network to manage the channel, which is used to realize secure Bitcoin off-chain payments.

BOLT #2 has three phases:

• channel establishment

• normal operation of the channel

• first level title

Threshold Cryptography

Our main innovation is the addition of threshold cryptography to the Lightning Network.

Sharing secrets is very common in real life, but we are going to borrow it 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 cryptocurrencies, theft of a private key (which should itself be a secret value) can result in the loss of funds. So, people came up with the idea of ​​splitting the key among multiple parties. In a threshold scheme, the key is split among multiple parties, and a threshold is predefined, below which the number of participants cannot know anything about the key anyway.

In order to use the Lightning Network on IoT devices without all the memory overhead, we leverage threshold cryptography.

This is also achievable, because we have isolated the Lightning Network nodes, and IoT devices only need to participate in the key cryptography.

first level title

image description

- Figure 2. Schematic diagram of system mode -

Our system has four main parts: (1) IoT devices; (2) Lightning gateways; (3) bridging Lightning nodes; (4) Targeting Lightning nodes.

Some assumptions:

Some assumptions:

IoT devices can connect to the Internet through gateways.

IoT devices and Lightning gateways will not be disconnected in the process of sending payments.

protocol

protocol

Suppose an IoT device now wants to pay the target Lightning Network node (such as paying tolls)

• Starting from the IoT Gateway, the device contacts the Lightning Network Gateway, which manages Lightning Network Nodes, Bitcoin Nodes and Threshold Servers

• Whenever an IoT device initiates a request, the Lightning Gateway opens a channel with the Bridge Lightning node to connect to the target network node

• Bridge network nodes can charge routing fees to Lightning Network gateways that initiate payments

• Payments for IoT devices are routed through bridge nodes to designated target nodes

• security analysis

security analysis

Here, we assume that our system will face three threats: collusion attack, IoT device collusion with lightning gateway, and ransom attack.

Conspiracy to attack:

1. Lightning gateway and bridge node collusion

In our system, payments are always sent from the IoT device to the target Lightning node, which in turn always increases the bridge node's balance in the channel. Therefore, the bridge node's old channel state balance will always be lower than the latest state, so this collusion cannot happen. Our protocol is currently limited to one-way payment, and it is future work to realize two-way payment for IoT devices.

Now, suppose the Lightning Gateway wants to broadcast the old state to the blockchain network. This is only beneficial if an old state of the Lightning Gateway has more funds than the current state. However, this is not possible because the Lightning Gateway will charge for every payment of the IoT device, and its balance will always increase. In addition, the old state balance of bridge nodes must also be low. Therefore, both of them have relatively low old state balances, and collusion is not beneficial.

(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 share a threshold private key to open channels with bridge nodes (multi-signature contract), but each commitment transaction has an output to allocate funds to the addresses controlled by IoT devices and gateways, instead of allocating funds to the threshold private key; therefore, the channel can make the balance of the gateway and the bridge node always increase. See the full paper attached at the end for details.)

2. IoT device and Lightning Gateway collude: Because the funds in the channel of the IoT device always fall as the payment occurs, it is easy to collude with the Lightning Gateway to broadcast an outdated state 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 specific to our protocol, but rather a problem with the Lightning Network in general.

Funds stolen from IoT devices:

Lightning gateways can steal funds promised by IoT devices by:

1. Send them to other Lightning Network nodes

2. broadcast the old state to the network

3. Collude with other Lightning Network nodes

If we use the original signature mechanism of the Lightning Network, the Lightning Gateway can take the funds of the IoT device in the channel without a signature from the IoT device. The modification we are proposing — using the (2-2) threshold scheme in Lightning Gateway’s Commitment Transactions — is precisely to protect IoT devices from losing funds. IoT device, since the channel is opened using a private key they jointly compute).

Ransomware attack:

This attack is a case where the Lightning Gateway deviates from the protocol description. For example, the gateway can tell the IoT device, "Give me as much bitcoin as you want, or I won't close the channel for you", or "From now on, you have to accept 10% service rate, why don't I give you Served."

At this time, the best way for IoT devices is to refuse to blackmail and keep consuming. The Lightning Gateway then withholds funds from the IoT device, delaying it as long as possible. This is an endless loop, and both sides are exhausted.

first level title

Applications and Experiments

The application scenarios of our agreement include electric vehicle charging piles, sensor data sales and parking lot charging systems. It’s better to take the toll booth at the beginning as an example, because we also did a field test.

Real-time response is most critical for tollbooths, because the ideal situation is that the car does not have to stop when passing the tollbooth, and the payment can be completed using (for example) a wireless network.

Whenever a vehicle enters the wireless coverage area of ​​a toll booth, it initiates a payment request to the lightning gateway of the toll booth through the IoT gateway. This Lightning Gateway immediately sends the requested payment amount to the charging company's Lightning Node. 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, let's assume that a car pays tolls twice a day. Assuming that the car has already opened the channel in advance, the only cost of using this service 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 amount of the toll. If there is a toll of $0.75 per trip, then the handling fee per payment is $0.0375, and the monthly service fee is only $2.50 (0.0375*60).

in conclusion

in conclusion

Our evaluation results show that Lightning Network nodes can support fast and timely IoT micropayments with low operating costs.

The goal of this research is to enable resource-constrained IoT devices to interact with the Lightning Network (which is generally not possible) and make 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 your trip, arrive in time, and don’t have to worry about paying tolls!

Our protocol can also be used in many other IoT micropayment applications (i.e. not limited to toll payments).

Our result is also a milestone in the development of a general framework for threshold cryptography for the Lightning Network. For all the details of the whole scheme, please see our paper.

Hope you gain something!