Written by: Amisha Shukla and Omer Shlomovits
Introduction:
Imagine you are traveling from point A to point B to attend an important meeting in your brand new car. On your way, you have to stop at three toll payment systems to give a toll tax. This slows you down and also wastes your time. Enter “automated payments system”.
Automatic payments in device-to-device (D2D) communication without any human intervention is a desired feature to solve this problem. Although it might be possible to link these devices to traditional payment systems such as credit cards, it requires third-party involvement which might bring management overhead as well as privacy concerns. In this aspect, cryptocurrencies play a crucial role to create a more convenient payment system. Thus, combining IoT and cryptocurrency systems(e.g. Bitcoin, Ethereum) can help address these challenges.
Bitcoin has emerged as a revolutionary payment system with its decentralized ledger concept however it has significant downsides for payments such as high transaction fees and long confirmation times.
Lightning Network(LN) solves these issues with an innovative concept called off-chain payments. With this advancement, Bitcoin has become an attractive venue to perform micro-payments which can also be adopted in many IoT applications. Nevertheless, it is not feasible to host LN and Bitcoin on IoT devices due to the storage, memory, and processing requirements.
LN currently exceeds 20,000 nodes since its emergence. IoT devices have limits on computation, communication, and storage requirements; thus, installing LN will not be possible on many resource-constrained IoT devices. Specifically, using LN requires running an LN node along with a full Bitcoin node which in total, occupies more than 340 GB of storage. Robust Internet connection and relatively high computation power are also necessary for Bitcoin block verification.
Considering all the scenarios, there’s a need for a lightweight solution. We propose a threshold cryptography-based protocol where an IoT device can perform LN operations through an untrusted LN gateway that hosts the full LN and Bitcoin nodes.
The LN gateway is incentivized to provide this payment service by the service fees it charges for sending IoT device’s payments.
We demonstrated that the proposed protocol
- enables realization of timely payments
- can be run on networks with low bandwidth (data rate)
- associated costs of using the protocol for IoT devices are negligible.
Lightning Network(LN):
In our protocol, we use the lightning network (LN). LNwas introduced in 2015 and later was implemented and deployed onto Bitcoin Mainnet by Lightning Labs and others. It is a second-layer peer-to-peer network on top of the Bitcoin blockchain.
LN aims to solve the scalability problem of Bitcoin.
It enables opening secure payment channels among users to perform instant and cheap Bitcoin transfers through multi-hop routes within the network by utilizing Bitcoin’s smart contract capability.
The number of users using LN has grown significantly since its creation. LN currently incorporates 59,192 channels i.e. 1,986.06 BTC.
We will use this example to make our understanding clear:
“ Alice wants to send payments to Bob and opens an LN payment channel to him. In a payment channel, the payments can flow in both directions between Alice and Bob to exchange funds without committing the transactions to the Bitcoin blockchain. This means that these transactions take place off-chain.”
One important building block of LN, as can be seen from figure 1 is the Commitment transaction. Commitment transaction has three outputs.
For Alice’s commitment transaction:
- Alice’s current balance in the channel which is time-locked.
- Bob’s balance in the channel which is immediately spendable by him.
- Payments contracts a.k.a HTLCs
Basis of Lightning Technology (BOLT):
For our protocol, we modified LN’s BOLT #2. Basis of Lightning Technology (BOLT) is LN’s peer protocol for channel management. BOLT is used for LN’s layer-2 protocol for secure off-chain Bitcoin payments.
BOLT #2 has 3 phases:
- Channel establishment
- Normal operation of channel
- Channel closing
Threshold Cryptography:
Our main innovation is by introducing threshold cryptography into LN.
Sharing secrets in the real world is quite common but we need to replicate the same in the digital world.
‘Threshold cryptography’ is a subset of Secure Multiparty Computation (SMPC) and deals with cryptographic operations where more than one party is involved.
In terms of cryptocurrencies, the stealing of private keys (secret) leads to the loss of funds. So, the idea of sharing a private key among several parties was suggested. In a threshold scheme, a secret is shared among multiple parties and a threshold is defined such that no group of parties less than the threshold can learn anything about the secret.
We are using the power of threshold cryptography to run lightning networks on IoT, without suffering from all the memory requirements.
This is achievable because we are separating the lightning node such that the IoT only participates in the important cryptography parts.
This actually speeds up the process and makes it easier to execute the entire process in a few seconds which also saves the cost.
System Model:
There are four main entities in our system model → (1) IoT device (2) LN gateway (3) Bridge LN node (4) Destination LN node
Other intermediaries include → (1) Threshold client (2) IoT gateway (3) LN gateway’s Bitcoin and LN nodes (4) Threshold server
Some assumptions:
IoT devices are connected to the internet using an IoT gateway.
We assume that the IoT devices and the LN gateway do not go offline in the middle of a process such as sending a payment.
IoT devices can be offline for the rest of the time.
Protocol:
Consider an IoT device that wants to pay the destination LN node for goods/services (e.g.a car paying a toll).
- Through the IoT gateway, IoT devices can reach the LN Gateway, which manages the LN & Bitcoin nodes and the threshold server.
- Whenever the IoT device makes a request, the LN gateway opens a channel to the Bridge LN node in order to connect to the Destination LN Node.
- Bridge LN node may charge a routing fee for payments initiated by the LN gateway.
- IoT device’s payments are routed to a destination LN node specified by the IoT device via bridge LN node.
- Now, the threshold operations are between the IoT device and the LN gateway, so only the LN gateway will run on the new modified protocol. Others can use the original protocol.
Security Analysis:
Here, we are assuming that there can be three threats to our system: Collusion Attack, IoT Device, and the LN Gateway Collusion and Ransom Attacks.
Collusion Attacks:
1) The LN Gateway and Bridge LN Node Collusion:
In our system, payments are always sent from the IoT device to some destination LN nodes which in turn always increases the balance of the bridge LN node on the channel. Thus, the bridge LN node has no old states in which it had more funds than it has in the most recent state, consequently invalidating the collusion. One-way payments are currently a limitation of the protocol and enabling bidirectional payments for the IoT device was left as future work.
Now, consider that the LN gateway broadcasts an old state to the blockchain. This is beneficial only if the LN gateway has an old state with more funds. However, this is not the case as the LN gateway charges the IoT device for each new payment which results in its channel balance always increase. Additionally, the bridge LN node also has fewer funds in the old states. Since both the LN gateway and the bridge LN node have fewer funds in old states, this collusion is unprofitable for them.
2) IoT Device and the LN Gateway Collusion: Since IoT device’s funds in the channel always decrease with each new payment, it is tempting for it to collude with the LN gateway to broadcast a revoked state to the blockchain together.
If the bridge LN node does not want to lose money, it must not go offline for extended periods of time. Therefore, again, this collusion is not specific to our protocol, but rather a general LN issue.
Stealing IoT Device’s Funds:
The LN gateway can steal IoT device’s funds that are committed to the channel by
- sending them to other LN nodes
- broadcasting revoked states
- colluding with the bridge LN node.
If we used LN’s original signing mechanism, the LN gateway could move the IoT device’s funds in the channel without needing a signature from the IoT device. Consequently, usage of (2,2)-threshold along with the proposed modifications to the LN gateway’s commitment transaction prevent IoT devices from losing any funds.
Ransom Attacks:
This is an attack where the LN gateway is deviating from the protocol description. To put it with some examples, the LN gateway can tell an IoT device that, “I will close this channel only if you pay me X amount of Bitcoins” or, “from now on, I will execute your payment sending requests only if you accept to pay an %10 increased service fee”.
Here, the best move would be that the IoT device must reject the ransom attempt and just wait. Then the LN gateway holds the IoT device’s funds hostage for as long as it can in an attempt to deter the IoT device. This is a deadlock case where both parties just wait.
The best course of action for the LN gateway is to continue serving IoT devices and keep collecting the service fees.
Applications and Experiments:
Some applications to our protocol include Electric Vehicle Charging, Sensor Data Selling, and Parking systems. We wish to focus on our canonical example of Toll payments, for which we also conducted measurements.
Real-time response is critical in a toll application where cars pass through a toll gate and pay the toll without stopping by utilizing wireless technologies.
When a car enters the communication range of the toll’s wireless system, it sends a request to the LN gateway of the toll gate through the IoT gateway to initiate the payment. The LN gateway immediately sends the requested amount of payment to the toll company’s LN node. After payment is successfully sent, a PaymentSuccess message is sent back to the car through the IoT gateway. For this to work, the whole payment sending process must be completed before the car gets out of the communication range of the toll gate’s wireless system.
Since the payment sending only takes 4.12 seconds, cars will be able to pay the toll on time.
For the cost, consider a car makes 2 toll payments in a day. Assuming that a channel was already opened for the car, the only cost of using the service will be the LN gateway’s service fees for each toll payment. While this service fee is decided by the LN gateway, let us assume that it is %5 on top of the actual toll amount. If the toll amount is $0.75 per pass, then the service fee is $0.0375 per payment. In 1 month, the total amount of service fees the LN gateway will be charging is only $2.25($0.0375 * 60).
Considering the convenience of making near-instant toll payments directly from your car, we believe paying an extra $2.25 in a month would be insignificant to the customers. In fact, credit card companies charge around similar or more fees.
Conclusion:
Our evaluation results show that LNGate enables fast and timely IoT micro-payments with minimal overhead.
The purpose of this research is to enable resource-constrained IoT devices that normally cannot interact with LN to interact with it and perform micro-payment transactions with other users.
To the best of our knowledge, this is the first work that implemented threshold cryptography in LN.
So, now you can enjoy your ride and reach just on time without worrying about your toll payment!
Our protocol can be used in many other IoT micro-payment applications (i.e. not limited to toll payments only).
This work is the first milestone in building a general framework for threshold lightning. To know more about the entire approach, go ahead and check out our research paper.
Happy Learning!
