LNGate^2: Secure Bidirectional IoT Micro-payments using Bitcoin's Lightning Network and Threshold Cryptography

Bitcoin has emerged as a revolutionary payment system with its decentralized ledger concept; however it has significant problems such as high transaction fees and low throughput. Lightning Network (LN), which was introduced much later, solves most of these problems 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 (e.g., toll payments). Nevertheless, it is not feasible to host LN and Bitcoin on IoT devices due to the storage, memory, and processing restrictions. Therefore, in this paper, we propose a secure and efficient protocol that enables an IoT device to use LN's functions through an untrusted gateway node. Through this gateway which hosts the LN and Bitcoin nodes, the IoT device can open close LN channels and send receive LN payments. This delegation approach is powered by a threshold cryptography based scheme that requires the IoT device and the LN gateway to jointly perform all LN operations. Specifically, we propose thresholdizing LN's Bitcoin public and private keys as well as its public and private keys for the new channel states (i.e., commitment points). We prove with a game theoretical security analysis that the IoT device is secure against collusion and stealing attacks. We implemented the proposed protocol by changing LN's source code and thoroughly evaluated its performance using a Raspberry Pi. Our evaluation results show that the protocol is fast, does not bring extra cost overhead and can be run on low data-rate wireless networks. To the best of our knowledge, this is the first work that implemented threshold cryptography in LN.

READ FULL TEXT VIEW PDF

page 14

page 17

05/19/2021

LNGate: Powering IoT with Next Generation Lightning Micro-payments using Threshold Cryptography

Bitcoin has emerged as a revolutionary payment system with its decentral...
12/19/2020

Enabling Micro-payments on IoT Devices using Bitcoin Lightning Network

Bitcoin's success as a cryptocurrency enabled it to penetrate into many ...
10/01/2018

Stronger Cryptography For Every Device, Everywhere

Generating secure random numbers is a central problem in cryptography th...
10/26/2018

LRCoin: Leakage-resilient Cryptocurrency Based on Bitcoin for Data Trading in IoT

Currently, the number of Internet of Thing (IoT) devices making up the I...
12/26/2018

Bitcoin Payment-channels for Resource Limited IoT Devices

Resource-constrained devices are unable to maintain a full copy of the B...
07/23/2019

Towards Secure IoT: Securing Messages Dissemination in Intelligent Traffic Systems

A few years ago, Automotive area in the IoT was seen as theoretical conc...
11/04/2017

Secure Communications using Nonlinear Silicon Photonic Keys

We present a secure communication system constructed using pairs of nonl...

1 Introduction

The last decade has witnessed a fast adoption of IoT in numerous domains as it provides great opportunities and convenience [gubbi2013internet]. These devices have typically been utilized for continuous data collection as they are equipped with various sensors. The improvement in their computational capabilities has enabled applications where an IoT device may pay/get paid for received/provided services. For instance, a vehicle passing through a toll gate can make a payment using its on-board unit which acts as an IoT device to communicate with the toll infrastructure [pavsalic2016vehicle]. Other potential micro-payment applications in this context include electric vehicle charging, parking payments, sensor data trading etc. [mercan2021cryptocurrency, kurt2020lnbot].

Since these micro-payments are generally device-to-device where no human intervention is involved, they should be automated. Although it might be possible to link these devices to traditional payment systems such as credit cards, this 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 experience. Thus, using cryptocurrency systems such as Bitcoin [nakamoto2009bitcoin] and Ethereum [wood2014ethereum] for IoT micro-payments might offer a more suitable option.

However; long confirmation times, low throughput, and high transaction fees have been the main concern in mainstream cryptocurrencies which limits their scalability [chauhan2018blockchain] as well as inhibits their adoption for micro-payment scenarios. Thus, payment channel network (PCN) idea was proposed which addresses these problems by utilizing off-chain transactions using a second layer on top of the blockchain [decker2015fast]. As an example, Lightning Network (LN) [poon2016bitcoin] has been introduced as a PCN solution for Bitcoin. LN currently exceeds 17,000 nodes since its creation four years ago. Although LN addresses the problems mentioned above, it still cannot be run on most of the IoT devices because of the computation, communication, and storage requirements [lniotproblem]. Specifically, using LN requires running an LN node along with a full Bitcoin node which in total, occupies more than 407 GB of storage at the time of writing this paper. Additionally, the devices need robust Internet connection and relatively high computation power to receive and verify the new Bitcoin blocks.

Therefore, a lightweight solution is needed to enable resource-constrained IoT devices to use LN for micro-payments. We are specifically focusing on Bitcoin’s LN and not Ethereum based PCNs because LN is currently the most widely used cryptocurrency payment channel network. To this end, in this paper, 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. With this integration, the IoT device can 1) open LN channels, 2) send LN payments, 3) receive LN payments, and 4) close LN channels. The LN gateway is incentivized to provide this payment service by charging service fees for IoT device’s payments.

In our proposed protocol, we utilize (2,2)-threshold cryptography to enable IoT device to control aforementioned LN operations without having to trust the LN gateway. The IoT device and the LN gateway cooperatively authorize channel operations by incorporating their threshold secret shares into signing and key generation operations. In this way, the LN gateway cannot spend IoT device’s funds in the channel without the IoT device joining in a (2,2)-threshold signing. We propose changes to LN’s peer channel protocol and commitment transactions. With these modifications, LN channels can also accompany IoT device’s funds while maintaining the existing security features of LN such as protection from cheating attempts from channel peers. We prove that our proposed protocol is secure against collusion and stealing attacks using a game theoretical security analysis.

To assess the effectiveness and overhead of the proposed protocol, we implemented it by changing the source code of one of the main LN implementations. In our test setup, we used a Raspberry Pi as the IoT device and a server desktop PC as the LN gateway. We demonstrated that the proposed protocol 1) has negligible computational and communication delays thus enables timely payments; 2) can be run on networks with low bandwidth (data rate); and 3) associated costs of using the protocol for IoT devices are negligible. In addition to those, we considered a real-life case where a vehicle at a certain speed makes toll payments through a wireless connection. We demonstrated that the proposed protocol enables realization of timely toll payments.

Contributions: Our contributions in this work are as follows:

  • [leftmargin=*]

  • We propose LNGate, a secure and lightweight protocol that enables resource-constrained IoT devices to open/close LN channels, send/receive LN payments through an untrusted gateway node.

  • We utilize (2,2)-threshold cryptography so that the IoT device does not have to get involved in Bitcoin or LN operations, but only in transaction signing and key generation. We propose to thresholdize LN’s Bitcoin public/private keys and public/private keys of new channel states (i.e., commitment points) for a secure 2-party threshold LN node.

  • We used game theory to analyze the security of the protocol and prove that it is secure against collusion and stealing attacks.

  • We implemented LNGate by changing LN’s source code. LN’s Bitcoin public and private keys were thresholdized. Our code is publicly available at our GitHub page: https://github.com/startimeahmet/lightning.

The rest of the paper is structured as follows. In Section 2, we discuss the related work. Section 3 describes the LN, threshold cryptography and game theory preliminaries. System and threat model are given in Section 4. The proposed protocol is explained in detail in Section 5. Section 6 presents a game theoretic security analysis of the protocol. Detailed performance evaluation of the proposed protocol is given in Section 7. Limitations of the approach is mentioned at Section 8. Finally, we conclude the paper in Section 9.

Fig. 1: Life cycle of an LN channel.

2 Related Work

Hannon and Jin [hannon2019bitcoin] propose a protocol based on LN to give the IoT devices the ability to transact. They propose using two third parties that they named IoT payment gateway and watchdog. However, their approach has a fundamental flaw. They assumed that the IoT device can open payment channels to the gateway and this process is not explained. This is indeed the exact problem we are trying to solve. IoT devices do not have the computational resources to open and maintain LN payment channels. Therefore, their assumption is not feasible and our work is critical in this sense to fill this gap.

The authors of [robert2020enhanced] proposed IoTBnB which is a digital IoT marketplace that utilizes LN payments for data trading. In their approach, an LN module which hosts the Bitcoin and LN nodes is used to send users’ payments. In contrast to our work, this approach is focusing on integrating LN into an existing IoT marketplace. Thus, the individual devices that are not part of such marketplaces are not considered. Additionally, the authors’ LN framework relies on Bitcoin wallets held by the ecosystem itself which raises security and privacy concerns. In our approach, IoT devices do not share the ownership of their Bitcoins with a third party.

A work focusing on Ethereum micro-payments rather than Bitcoin was proposed by Pouraghily and Wolf [pouraghily2019lightweight]. It is a ticket-based verification protocol to enable low-end IoT devices to exchange money and data inside an IoT ecosystem. However, this approach has major problems: The joint account opened with a partner device raises security concerns as the details of it are not provided. Additionally, the approach was compared with Raiden [raiden] whose development stopped 4 years ago. In contrast to this work, we targeted Bitcoin’s LN as it is actively being developed and dominating the market.

A recent work by Rebello et al. [rebello2021securing] proposed a hybrid PCN architecture for wireless resource constrained devices to be able to access and use PCNs. However, their solution does not work for devices that stay offline for long periods of time. Additionally, authors assume that resource-constrained devices can run light nodes and establish payment channels. This assumption cannot be generalized to all the IoT devices. Our approach does not require IoT devices to stay online except for the time they perform the LN operations. They also do not need to run light nodes.

Another recent work by Wang et al. [wang2021hyperchannel] introduced HyperChannel which utilizes a group of Intel Software Guard Extensions (SGXs) that are run by selfish service nodes to execute the transactions. The approach includes an entity called client emergency enclave. This is an extra burden on the IoT devices since each device has to own an emergency enclave to protect themselves in case of service node shutdowns. In our approach, we only require IoT devices to perform signing.

Profentzas et al. [profentzas2020tinyevm] proposed TinyEVM to enable IoT devices to perform micro-payments. The authors’ method involves running a modified version of Ethereum virtual machine on the IoT devices. In contrast, in our approach, IoT devices only generate signatures which is not a resource-intensive operation. The work by Li et al. [li2020data] focuses on designing a PCN-based smart contract for IoT data transactions. However, they do not seem to discuss the costs associated with their protocol and routing performance of the protocol drops significantly when there are malicious nodes in the network. A slightly different work by Tapas et al. [tapas2020p4uiot] proposed utilizing LN in the context of patch update delivery to the IoT devices where they claim rewards through LN. However, unlike our work, the IoT devices are assumed to be able to connect to the blockchain through light clients or third party full nodes on the network which requires a degree of trust.

There are also some implementation efforts for creating lighter version of LN such as Neutrino [neutrino] light client and Phoenix [phoenix] mobile wallet. The problem with these software is that they are not specifically designed for IoT devices thus most IoT devices cannot run them. Thus, we opt for a solution that covers a wider range of IoT devices and applications.

We would like to note that this work is an extension of our conference paper [kurt2021lngate] with a lot of additions and improvements as follows: 1) The proposed protocol in the conference version only supports unidirectional payments. In this paper, we proposed a new protocol where the IoT device can also receive payments in addition to sending; 2) In the conference version, the security of the protocol against collusion and stealing attacks was not analyzed formally. In this journal version, we use game theory to comprehensively analyze the collusion and stealing attacks formally by considering both unidirectional and bidirectional payment cases; 3) The evaluation section in the conference version only has limited WiFi experiments. In this paper, we present Bluetooth Low Energy (BLE) experiments in addition to the WiFi. Specifically, we designed and implemented an IP over BLE solution to enable end-to-end connection for BLE-based IoT devices. Overall, we offer more experiments, analysis and details; 4) Overall, almost all the sections from the conference version is either rewritten, modified significantly or extended.

3 Background

This section provides background on LN, its underlying mechanisms, threshold cryptography and game theory as a preliminary to our proposed approach.

3.1 Lightning Network Preliminaries

LN was introduced in 2015 in a draft technical whitepaper [poon2016bitcoin] and later was implemented and deployed onto Bitcoin Mainnet by Lightning Labs [lnlaunch]. It runs on top of the Bitcoin blockchain as a second-layer peer-to-peer distributed PCN and aims to address 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 [contract]. The number of users using LN has grown significantly since its creation. At the time of writing this paper, LN incorporates 17,466 nodes and 84,314 channels which hold 3818 BTC in total (worth around 115 Million USD)111https://1ml.com/.

The rest of this section explains technical concepts about LN such as funding transaction, commitment transaction, Hash Time Locked Contract (HTLC), revoked state, key send & invoice payments and basis of lightning technology which are essential to understand our protocol. The explanations are based on an example case where Alice opens an LN payment channel to Bob and wishes to transact with him.

Funding Transaction: When Alice would like to open a channel to Bob, this is done via an on-chain Bitcoin transaction called the funding transaction. Generally the channel is funded by the party initiating the process, but dual-funding where both channel parties commit funds to the channel is also possible. With the funding process, the capacity of the channel is determined as well. For example, if Alice funds the channel with 10 Bitcoins (BTC) as shown in Fig. 1 (1. Channel Opening), she can send payments to Bob until her 10 BTC in the channel are exhausted.

The reverse of the funding transaction is the closing transaction which is used to close an LN channel (3. Channel Closing in Fig. 1). This is also an on-chain transaction which needs to be broadcast to the Bitcoin network.

Fig. 2: An illustration of the commitment transaction stored at Alice.

Commitment Transaction: Once the channel is used for sending a payment, the balances of Alice and Bob in the channel will change. Since the LN payments are off-chain meaning they are not recorded on the Bitcoin blockchain, another type of Bitcoin transaction which will keep track of the channel balances is needed. This is done by the commitment system of LN. A simple LN payment requires two separate commitment rounds: one when the payment is offered and one when it is fulfilled. Each commitment round requires both peers to sign a commitment transaction. Here, the commitment transactions are what actually hold the channel balance information and incoming/outgoing payments. They are specially crafted for LN and symmetrical for channel peers. An illustration of this is shown in Fig. 1 (2. Payment Sending) where Alice initiates a 1 BTC payment to Bob and their channel balances get updated.

Inputs to Alice’s commitment transaction is the funding transaction outpoint and Bob’s signature. Outpoint is the combination of the transaction output and its output index. A typical commitment transaction has three main outputs. For Alice’s version, the first output is for her balance, the second output is for Bob’s and the third would be for an incoming/outgoing payment. These outputs are illustrated in Fig. 2.

HTLC: LN payments are constructed using a special type of transaction called Hash Time Locked Contract (HTLC). In this scheme, when Alice wants to send a 1 BTC payment to Bob as depicted in Fig. 1 (2. Payment Sending), she asks Bob to generate a secret called preimage. Bob hashes the preimage and sends the hash to Alice. Alice includes the hash in the HTLC and sends the HTLC to Bob. Upon receiving Alice’s HTLC, Bob reveals the preimage to Alice to receive the 1 BTC payment. This acts as a proof that Bob is the intended recipient. If for some reason, Bob cannot reveal the preimage on time to claim the HTLC, Alice gets the 1 BTC back after some block height w. Output 3 in Fig. 2 illustrates this HTLC payment.

Revoked State: Alice’s balance in her commitment transaction is conditional such that; if she closes the channel, she has to wait k number of blocks before she can redeem her funds on-chain. This is to prevent Bob from a possible cheating attempt from Alice in which she uses an old (revoked) channel state to close the channel. Since Alice has a record of all the old channel states, it might be tempting for her to broadcast an old state in which she has more funds. But, if Bob sees that the channel was closed using an old state, he will punish Alice by taking all her funds in the channel. But to do that, he has to be online and take action before the broadcast transaction reaches the depth k on the blockchain. Note that, when Alice closes the channel, Bob can redeem his funds immediately unlike Alice.

Key Send & Invoice Payments: LN payments are sent using invoices which are basically long strings consisting of characters and numbers222https://github.com/lightning/bolts/blob/master/11-payment-encoding.md. They are encoded in a specific way to include all the information required to send the payment such as the destination public key, payment amount, expiration date, signature etc. The recipient of the payment prepares the invoice and sends it to the payer. A more convenient payment method which does not involve such preparation in LN is called key send333https://github.com/lightningnetwork/lnd/pull/3795. With this method, senders do not need to contact the recipients or need to have an invoice first to send payments.

Basis of Lightning Technology (BOLT): BOLT specifications describe LN’s layer-2 protocol for secure off-chain Bitcoin payments. In order to implement our proposed protocol, we made modifications on BOLT #2 which is LN’s peer protocol for channel management. BOLT #2 has three phases which are channel establishment, normal operation of the channel, and channel closing. Using this protocol, LN nodes talk to each other for channel related operations. The full details of the protocol can be found at [bolt2].

3.2 Threshold Cryptography

Threshold cryptography [desmedt1994threshold] deals with cryptographic operations where more than one party is involved. The idea of sharing a cryptographic secret among a number of parties was proposed by Shamir [shamir1979share]. In a threshold scheme, a secret is shared among parties and a threshold is defined such that, no group of can learn anything about the secret. Such setup is defined as -threshold scheme. We utilize (2,2)-threshold cryptography in our proposed protocol for cooperative signing and key generation. Since Bitcoin is using Elliptic Curve Digital Signature Algorithm (ECDSA) for signing operations, in the next sections, we first present the ECDSA signature scheme. Then, we give the details of the 2-party ECDSA threshold key generation and signing that we employ in our protocol. They are rewritten from [gothamcitywhitepaper] and based on Lindell’s work [lindell2017fast].

ECDSA Signature Scheme: ECDSA signature scheme takes an input message and a private key and produces a pair of integers as output. The steps of the algorithm are as follows:

  1. [leftmargin=*]

  2. Hash of the message is calculated. is a hash function (i.e., SHA-256).

  3. A secure random integer between is generated.

  4. A random point is calculated. Then, is computed.

  5. Signature proof is calculated.

  6. is returned which is the ECDSA signature.

(2,2)-Threshold Key Generation: Let be an elliptic curve of prime order and a base point (generator) . In our setting, the protocol is run between a server and a client .

  1. [leftmargin=*]

  2. Initiation: Choosing a random , the server computes and choosing a random , the client computes .

  3. A variant of the ECDH key exchange (see [lindell2017fast]) is run by the client and the server to generate the joint public key .

  4. A Paillier key-pair is generated and is computed by the server where is the Paillier public key. Then, the server sends and to the client.

  5. The client receives a non-interactive zero-knowledge proof whose Paillier key is well-formed from the server. Proof in [cryptoeprint:2018:057] as well as the parameters in [lindell2018fast] were utilized.

  6. The client asks the server to prove that the encrypted value in is the discrete log of using a 2-round zero-knowledge protocol that is given at Section 6 of Lindell’s work [lindell2017fast].

  7. The client asks the server to prove that where is the order of the elliptic curve using a 2-round zero-knowledge protocol that is given at Appendix A of Lindell’s paper [lindell2017fast].

(2,2)-Threshold Signing: This 2-party threshold ECDSA algorithm produces the same signature as the original ECDSA signature scheme given earlier.

  1. [leftmargin=*]

  2. Step 1 of the key generation protocol is repeated for ephemeral key-pairs by the server and the client. This outputs for the server and for the client.

  3. Server and the client can extract the -coordinate from the same they generate by and respectively.

  4. and are computed by the client where is some random number. Then, is computed and sent to the server by the client where is the additive homomorphic operation of Paillier cryptosystem.

  5. is decrypted by the server to get which is used to compute . Now, server outputs as the ECDSA signature if validates as a signature on .

3.3 Game Theory Background

In this paper, the concept of subgame perfect equilibrium [moore1988subgame] plays an important role to identify the solution. A (proper) subgame is a subset of the tree structure of the actual game. When tree form is used in a game, sequentiality can be applied rather than simultaneity. That is, in a two-player game, one player moves first and the other decides how to play after observing the first player’s action. In this setting, it is assumed that the players are all sequentially rational, meaning that each player systematically and purposefully performs his/her best to achieve the objective. Most of the time, the objective for a player in an economic setting is to maximize profit. One should also note that profit maximization requires the cost minimization at the same time by its definition. This structure can be extended to more than two players, where we focus on three players in our model, without loss of generality.

To find the solution of a game with a similar setting, i.e., subgame perfect equilibrium (SPE), the concept called backward induction [aumann1995backward] can be used. Applying the backward induction procedure requires investigating the game from the end to the start. Particularly, at each decision node, any action that results in a smaller payoff for the corresponding player is eliminated. Incorporating sequential rationality, a strategy profile is SPE if it specifies a Nash equilibrium (NE) [myerson1978refinements] in every subgame of the original game. A Nash equilibrium is the optimal solution which yields no incentive for any player in the game to deviate once it is achieved.

Fig. 3: Illustration of the system model.
Fig. 4: Depiction of the proposed commitment transactions for the LN gateway and the bridge LN node. These commitment transactions are generated after the following operations: 1) A channel with 10 BTC capacity was opened, 2) IoT requested sending 1 BTC to a destination, 3) Gateway charged the IoT a service fee of 0.1 BTC for this payment (the fee in real life would be much less).

4 System & Threat Model

4.1 System Model

There are four main entities in our system which are IoT device, LN gateway, Bridge LN node, and Sender/receiver LN node as shown in Fig. 3. We also show other tools and intermediary devices; Threshold client, IoT gateway, LN gateway’s Bitcoin and LN nodes, Threshold server. IoT device wants to pay the receiver LN node for the goods/services. It can also receive payments if needed such as a refund or a payment from another LN node (sender LN node). In other words, payments are bidirectional meaning that the IoT device can both send and receive payments. It is connected to an IoT gateway acting as an access point utilizing a wireless communication standard such as WiFi, Bluetooth, 5G, etc. depending on the IoT application. The IoT gateway is responsible for connecting the IoT device to the LN gateway when the IoT device is within its range. Through this connection, IoT device can talk to the LN gateway, which manages the LN & Bitcoin nodes and the threshold server. The LN gateway can be hosted on the cloud or locally depending on the use case scenario. It provides services to the IoT device by running the required full Bitcoin and LN nodes and is incentivized by the fees IoT device pays in return. The LN gateway also runs a threshold server that communicates with the threshold client installed at the IoT device when required. This client/server setup enables the 2-party threshold ECDSA operations. Bridge LN node is the node to which the LN gateway opens a channel when requested by the IoT device. Through the bridge LN node, IoT device’s payments are either routed to a receiver LN node specified by the IoT device or delivered to the IoT device from a sender LN node on the Internet.

We assume that the IoT device and the LN gateway do not go offline in the middle of a process such as sending or receiving a payment. IoT device can be offline for the rest of the time.

4.2 Threat Model

We make the following security related assumptions:

  • [leftmargin=*]

  • The LN gateway is malicious and it can post old (revoked) channel states to the blockchain. It can gather information about IoT devices and can try to steal/spend funds in the channel.

  • We assume that the LN gateway and the bridge LN node can collude with each other.

  • We assume that the communication between the IoT device and the LN gateway is secure (i.e., TLS/DTLS).

We consider the following attacks to our proposed system:

  • [leftmargin=*]

  • Threat 1: Collusion Attacks: The LN gateway and the bridge LN node can collude against the IoT device to steal money from it.

  • Threat 2: Stealing IoT Device’s Funds: The LN gateway can steal IoT device’s funds that are committed to the channel by 1) sending them to other LN nodes, and 2) broadcasting revoked states.

In Section 6, we present the security analysis using game theory to show how our proposed protocol is resistant against the attacks mentioned above.

5 Proposed Protocol Details

This section explains the details of the protocol that includes the channel opening, sending a payment, receiving a payment and channel closing. As mentioned in Section 3.1, we propose modifications to LN’s BOLT #2 which are shown throughout the protocol descriptions. More importantly, LN’s signing mechanism is modified and replaced with a (2,2)-threshold scheme that is utilized by the IoT device and the LN gateway. In addition to that, we propose changes to LN’s commitment transactions to accompany IoT device’s funds in the channel which is explained next.

5.1 Modifications to LN’s Commitment Transactions

Introduction of the IoT device requires some modifications to LN’s commitment transactions as there are now 3 channel parties instead of 2. Since each channel party has a separate balance in the channel, they have to have an output in the commitment transaction reflecting their balance. An illustration of LN’s original commitment transaction was given in Fig. 2.

Our proposed modified version of LN’s commitment transactions are shown in Fig. 4. As can be seen, there is an extra output for the IoT device in both versions of the commitment transaction. This output is not time-locked nor conditional unlike others as the IoT device will not be punished because of a cheating attempt from other channel parties. This essentially protects IoT device’s funds in the channel. Apart from that, the LN gateway’s and bridge LN node’s outputs are regular time-locked outputs and are spendable by the counterparty in case of a cheating attempt.

5.2 Channel Opening Process

The IoT device is not able to open a channel by itself as it does not have access to LN nor Bitcoin network. Therefore, we enable the IoT device to securely initiate the channel opening process through the LN gateway and jointly generate signatures with it using the (2,2)-threshold scheme. This means that LN’s current channel opening protocol needs to be modified according to our needs.

All the steps for the channel opening protocol which includes the default LN messages and our additions are depicted in Fig. 5. We explain the protocol step by step below:

Fig. 5: Protocol steps for opening a channel. Messages in red show the default messages in BOLT #2.
  • [leftmargin=*]

  • IoT Channel Opening Request: IoT sends an OpenChannelRequest message (Message #1 in Fig. 5) to the LN gateway to request a payment channel to be opened to a bridge LN node. This message has the following fields: Type: OpenChannelRequest, Channel Capacity, Bridge LN Node. Channel Capacity is specified by the IoT device and this amount of Bitcoin is taken from IoT device’s Bitcoin wallet as will be explained in the next steps. Here, we opt to let the IoT device choose the bridge LN node since letting the LN gateway choose the bridge LN node might not be secure as will be shown in Section 6. IoT device can make this choice through accessing API services that provide public LN information444e.g., https://amboss.space/.

  • Channel Opening Initiation: Upon receiving the request from the IoT device, the LN gateway initiates the channel opening process by connecting to the bridge LN node specified by the IoT device. Before initiating the channel opening process by sending an open_channel message, we propose the LN gateway to perform a (2,2)-threshold key generation with the IoT device to thresholdize its funding_pubkey (#2 in Fig. 5). The funding_pubkey is a Bitcoin public key and both channel parties have their own. This process replaces the LN gateway’s Bitcoin public and private keys with a threshold public/private key pair that is jointly computed between the IoT device and the LN gateway. In this way, the LN gateway cannot spend the funds the IoT device is committing to the channel without the IoT device’s authorization. After this step, the LN gateway sends the open_channel message (#3 in Fig. 5) to the bridge LN node which includes the thresholdized funding_pubkey. The channel capacity specified by the IoT device is also sent with this message. After this step, the bridge LN node responds with an accept_channel message (#4 in Fig. 5) to acknowledge the channel opening request of the LN gateway. Note that, open_channel and accept_channel are default BOLT #2 messages.

  • Creating the Transactions: Now that the channel parameters are agreed on, the LN gateway can create a funding transaction from IoT device’s Bitcoin address to the 2-of-2 multisignature address of the channel. Since the input to the funding transaction is from the IoT device’s BTC address, IoT device can also pay the on-chain fee for this transaction555Custom funding transactions like this can be constructed by first creating a partially signed Bitcoin transaction (PSBT), then adding the inputs externally and finalizing it in LN. See: https://lightning.readthedocs.io/lightning-openchannel_init.7.html. At this step, the LN gateway also creates the commitment transaction for itself and the bridge LN node (#7 in Fig. 5). Here, we propose to compute the first commitment point jointly between the IoT device and the LN gateway. Commitment points are used to derive revocation keys and they are unique for each channel state. Thus, thresholdizing the commitment points prevents the IoT device and the LN gateway from single-handedly revealing the revocation key before the channel state is updated. For this, we propose to use a (2,2)-threshold child key derivation process (#6 in Fig. 5) also known as, 2P-HD [gothamcitywhitepaper]. 2P-HD allows the derivation of child keys from the master key that was already generated with (2,2)-threshold key generation earlier (#2 in Fig. 5). We propose using 2P-HD over (2,2)-threshold key generation because of its efficiency.

  • Exchanging Signatures: Now, the LN gateway needs to send the signature for bridge LN node’s version of the commitment transaction to the bridge LN node. For this, the LN gateway and the IoT device jointly generates the signature in a (2,2)-threshold signing (#8 in Fig. 5). After signing is done, the LN gateway sends the signature to the bridge LN node along with the outpoint of the funding transaction in a funding_created message (#9 in Fig. 5). Learning the funding outpoint, the bridge LN node is now able to generate the signature for the LN gateway’s version of the commitment transaction and sends it over to the LN gateway in funding_signed message (#10 in Fig. 5).

  • Broadcasting the Transaction to the Bitcoin Network: After the LN gateway receives the funding_signed message from the bridge LN node, it must broadcast the funding transaction to the Bitcoin network (#11 in Fig. 5). Then, the LN gateway and bridge LN node should wait for the funding transaction to reach a specified number of confirmations on the blockchain (generally 3 confirmations). After reaching the specified depth, the LN gateway and the bridge LN node exchange funding_locked messages which finalizes the channel opening (#12-13 in Fig. 5).

5.3 Sending a Payment

Similar to the channel opening, we incorporate the IoT device in threshold operations to authorize a payment sending. The same threshold schemes are utilized and LN’s current payment sending protocol is modified. The steps of the proposed payment sending protocol is depicted in Fig. 6 and elaborated below:

Fig. 6: Protocol steps for sending a payment. Messages in red show the default messages in BOLT #2.
  • [leftmargin=*]

  • Payment Sending Initiation: To request a payment sending, IoT device sends a SendPayment message (#1 in Fig. 6) to the LN gateway. This message has the following fields: Type: SendPayment, Payment Amount, Destination Node ID. Here, we assume that the Destination Node ID is either interactively provided to the IoT device in some form (i.e., QR code) by the vendor (i.e., toll gate) just before the payment or it is known by the IoT device in advance.

  • Payment Processing at the LN Gateway: Upon receiving the request, the LN gateway adds an HTLC output to bridge LN node’s version of the commitment transaction (#2 in Fig. 6). When preparing the HTLC, the LN gateway deducts a certain amount of fee from the real payment amount IoT device wants to send to the destination. Therefore, the remaining Bitcoin is sent with the HTLC. This fee is taken to incentivize the LN gateway to continue serving the IoT devices. The LN gateway then sends an update_add_htlc message (#3 in Fig. 6) to actually offer to HTLC to the destination LN node which is first received by the bridge LN node and then other nodes on the payment path (destination LN node is not shown in Fig. 6 for simplicity). Here, the destination node ID, specified by the IoT device, is embedded into the onion routing packet which is sent with the update_add_htlc message.

  • 1st Commitment Round: In LN, HTLCs always require two rounds of commitment_signed and revoke_and_ack. First round is for invalidating the old channel state right before the HTLC is attached to the channel. The second one is to fulfill the HTLC to remove it from the channel. Thus, at this point, the LN gateway will initiate the first round by sending a commitment_signed message to the bridge LN node. For that, it jointly generates a signature with the IoT device in a (2,2)-threshold signing (#4 in Fig. 6). The HTLC signature is also jointly generated at this step. Once the commitment and HTLC signatures are generated, they are sent to the bridge LN node in the commitment_signed message (#5 in Fig. 6). These signatures will enable bridge LN node to spend the new commitment transaction and the HTLC output. The bridge LN node responds to this message by first sending a revoke_and_ack then a commitment_signed message (#6-7 in Fig. 6). Symmetrically, now the LN gateway will send a revoke_and_ack message but before that we propose the LN gateway and the IoT device to thresholdize the new commitment point in a 2P-HD (#8 in Fig. 6). Once this is done, the LN gateway sends the revoke_and_ack message (#9 in Fig. 6).

  • Fulfilling the HTLC: Now, the next step is for bridge LN node to fulfill the HTLC with a similar symmetric commitment_signed & revoke_and_ack round. Thus, it sends an update_fulfill_htlc message to the LN gateway (#10 in Fig. 6) then a commitment_signed message (#11 in Fig. 6) to initiate the second round of commitments. This will be followed by the LN gateway sending a revoke_and_ack message. However, the LN gateway first performs a 2P-HD with the IoT device to thresholdize the new commitment point (#12 in Fig. 6). After sending the revoke_and_ack message (#13 in Fig. 6), the next step is to send the commitment_signed message. To generate the signature, the LN gateway performs a (2,2)-threshold signing (#14 in Fig. 6) with the IoT device then sends the commitment_signed message (#15 in Fig. 6). Finally, the bridge LN node replies with a revoke_and_ack message to irrevocably fulfill the HTLC (#16 in Fig. 6).

  • Notifying IoT: Now that the payment is successfully sent, the LN gateway can notify the IoT device of the successful payment by sending a PaymentSendSuccess message (#17 in Fig. 6).

5.4 Receiving a Payment

Receiving payments on the channel is a bit different than other channel operations as it does not require the IoT device to send a request to the LN gateway. Rather, an LN node on the Internet initiates a payment to the IoT device which needs to be received on the channel that the LN gateway opened for it. Normally, when sending a payment on LN, it is enough to only specify the recipient’s LN public key. If the recipient has multiple channels that can receive the payment, then the payment might end up at any of them. The exact channel that will receive the payment is internally decided by LN’s routing algorithm. For our context, since the LN gateway has multiple channels each of which might be serving different IoT devices, receiving a payment on a specific channel becomes an important problem to tackle. In this direction, a sender LN node can force its payment to take a predetermined path which is also known as the source routing. By querying the possible routes to the recipient node, a sender LN node can decide all the channels to use before sending the payment. We propose that the LN gateway do not charge a service fee for receiving payments. The proposed protocol for this is explained in detail below:

Fig. 7: Protocol steps for receiving a payment. Messages in red show the default messages in BOLT #2.
  • [leftmargin=*]

  • Calculating a Route: We assume that the sender LN node already knows to which IoT device to initiate the payment and the channel ID belonging to that IoT device (i.e., the channel the LN gateway opened to the bridge LN node for this specific IoT device). Knowing the channel ID, the sender LN node can calculate a route from its LN node to the LN gateway’s LN node where the channel belonging to the IoT device is the last channel on the route. After calculating the route, the sender LN node can prepare a key send payment that will use this specific route.

  • 1st Commitment Round: The sender LN node can initiate the payment by sending an update_add_htlc message (#1 in Fig. 7) to the LN gateway which will be relayed to all the nodes on the payment path including the bridge LN node (sender LN node is not shown in Fig. 7 for simplicity). At this stage, similar to the payment sending case, there are going to be two rounds of commitment_signed and revoke_and_ack. The bridge LN node initiates the first round by sending a commitment_signed message to the LN gateway to commit the initial changes on the channel (#2 in Fig. 7). Here, before sending a revoke_and_ack message, the LN gateway performs a threshold 2P-HD (#3 in Fig. 7) with the IoT device to thresholdize the next commitment point. Then, it sends the revoke_and_ack message (#4 in Fig. 7). Now, the LN gateway needs to send a commitment_signed message to the bridge LN node. Thus, to generate the signature, it performs a (2,2)-threshold signing with the IoT device (#5 in Fig. 7). Then, the commitment_signed message is sent (#6 in Fig. 7) and a revoke_and_ack is received (#7 in Fig. 7) from the bridge LN node.

  • Fulfilling the HTLC: Messages #2-7 made sure that the old channel state is invalidated so the bridge LN node cannot pretend the HTLC never existed. Now, the next step is to fulfill the HTLC with a similar symmetric commitment_signed & revoke_and_ack round. Thus, the LN gateway first sends an update_fulfill_htlc message (#8 in Fig. 7). Then, the LN gateway and the IoT device generate a signature in a (2,2)-threshold signing (#9 in Fig. 7) which is sent to the bridge LN node in a commitment_signed message (#10 in Fig. 7). Bridge LN node responds by first sending a revoke_and_ack message (#11 in Fig. 7) then a commitment_signed message (#12 in Fig. 7). Finally, before sending the revoke_and_ack, the LN gateway again performs a threshold 2P-HD with the IoT device to thresholdize the next commitment point (#13 in Fig. 7). It then sends the revoke_and_ack message (#14 in Fig. 7) which fulfills the HTLC irrevocably.

  • Notifying IoT: Now, it is a good time for the LN gateway to let the IoT device know that the payment is successfully received. Thus, it sends a PaymentReceiveSuccess message to the IoT device.

5.5 Channel Closing Process

A channel in LN is closed either unilaterally by one of the parties broadcasting its most recent commitment transaction to the blockchain or closed mutually by both parties agreeing on the closing fee. In our case, all 3 parties of the channel namely; the IoT device, the LN gateway, and the bridge LN node can close the channel. We explain all three cases separately below:

5.5.1 IoT Device Channel Closure

When the IoT device would like to close the channel, it follows the proposed protocol below.

  • [leftmargin=*]

  • IoT Device Channel Closing Request: The IoT device sends a ChannelClosingRequest message to the LN gateway.

  • Mutual Close: The LN gateway has two options to close the channel which are unilateral or mutual close. In mutual close, the LN gateway and the bridge LN node first exchange shutdown messages and then start negotiating on the channel closing fee. For this, they start exchanging closing_signed messages. This message includes the offered fee and offering party’s signature. Thus, each time the LN gateway sends a closing_signed message, it has to perform a (2,2)-threshold signing with the IoT device to generate the signature. Once the closing fee is agreed upon, the closing transaction is broadcast to the blockchain by the LN gateway.

  • Unilateral Close: In the unilateral close case, the LN gateway just broadcasts its most recent commitment transaction to the Bitcoin network after getting it (2,2)-threshold signed with the IoT device. We propose the on-chain fee for both cases to be paid by the IoT device since the channel closing was requested by the IoT device. The fee is deducted from the IoT device’s Bitcoin wallet. Once the broadcast transaction is mined, the channel is closed and everyone’s funds in the channel settle in their respective Bitcoin addresses.

5.5.2 LN Gateway Channel Closure

The LN gateway can also initiate the channel closing if it wants to close IoT device’s channel for any reason. The steps are very similar to IoT device channel closure case and explained below:

  • [leftmargin=*]

  • LN Gateway Channel Closing Request: The LN gateway sends a ChannelClosingRequest message to the IoT device to show its intention to close the channel.

  • Closing the Channel: The LN gateway can close the channel unilaterally or mutually. For either case, it needs the IoT device to participate in a (2,2)-threshold signing. The steps for closing the channel are exactly the same of the IoT device channel closure case explained above. The only difference is that, since now the channel closing is requested by the LN gateway, the on-chain fee is paid by the LN gateway by deducting the fee from its Bitcoin wallet.

5.5.3 Bridge LN Node Channel Closure

The bridge LN node can close the channel unilaterally or mutually. A mutual close from the bridge LN node will trigger a fee negotiation phase with the LN gateway which involves exchanging closing_signed messages. Since this requires the IoT device to be online and participate in (2,2)-threshold signing with the LN gateway; the bridge LN node might have to close the channel unilaterally if the IoT device is not online at the time of the mutual close attempt. For the unilateral close, the bridge LN node can just broadcast its most recent commitment transaction to the blockchain.

6 Game Theoretic Security Analysis of the Protocol

In order for the proposed protocol to function properly, each party involved in the channel must have the peace of mind that their share of the funds in the channel are always secure meaning it cannot be stolen by other parties. In our preliminary version of this work [kurt2021lngate], we informally analyzed the security of the proposed protocol that is only capable of unidirectional payments. When the IoT device does not need to receive payments on the channel the LN gateway opened for it, there is no possibility of its funds getting stolen by the LN gateway or the bridge LN node. However, this is not the case for bidirectional payments where the IoT device can also receive payments from other nodes in LN. The problem is, if the IoT device receives a payment, it will have some old states in which it has less money. Thus, the bridge LN node or the LN gateway can publish these old channel states to the blockchain to cheat and profit. To better illustrate how this can happen, we will use a sequential game approach using game theory and present the actions of each party that leads to various outcomes. Then, we will present the Nash equilibrium for each case using backward induction. We assume that all players act rationally to maximize their profits. First, we analyze the security of the unidirectional payments case which we introduced in our prior work [kurt2021lngate]. Then, we analyze the security of the bidirectional payments case which we introduce in this work.

6.1 Unidirectional Payments

Unidirectional payments can be as common as bidirectional payments for IoT devices. A good example is cars paying for toll when they pass a toll booth using a dedicated IoT device attached onto them. In this case, the payments will always be from the cars to the toll company, thus unidirectional. Next, we present the game model.

6.1.1 The Game Model

The Bridge LN Node Broadcasts a Revoked State: The game theoretical model in an extensive form, i.e., tree-form is shown in Fig. 8 and set up as follows: There are three players in this game: IoT device (IoT), Bridge LN node (Bridge) and LN gateway (Gateway). IoT has one decision node where two possible decisions are whether to open a channel or not. When IoT chooses not to open any channels, each player will end up with zero payoff. In the event that IoT chooses to open a channel, channel goes into the normal operation phase where it can be used to send and receive payments.

For our case, we focus on the channel closing phase as that is how parties attempt to cheat. Both the Gateway and Bridge can initiate a channel closing. First, we show the case where Bridge initiates the channel closing. So, at this decision node, Bridge has to make a decision to close the channel normally or broadcast a revoked state to the blockchain. If Bridge plays to close the channel normally, the game ends at this terminal node with the payoffs of BTC, BTC and BTC for IoT, Bridge and Gateway, respectively, where , , .

Fig. 8: Payoffs for Unidirectional Payments Case when Bridge Broadcasts a Revoked State

If Bridge chooses to broadcast a revoked state, the Gateway gets to play at its first decision node in this game. At this node, Gateway chooses to be online or offline. Even though we say it is a choice, it is actually a state for the Gateway. Most LN nodes try to stay online at all times to prevent loss of funds but downtimes do occur. If Gateway plays to be offline (or simply if the Gateway is offline), the game ends at this terminal node and IoT obtains a payoff of , Bridge gets and Gateway ends up with . In old states of unidirectional payments, IoT always has more funds; Bridge and Gateway always have less funds. Thus, can be written as where is the amount of extra BTC the IoT has in the old state. Similarly, can be written as where is the small amount of BTC the Gateway loses. Consequently, will be equal to . Here, we can also find that since we know . When the game ends at this terminal node, it implies that Bridge successfully broadcasts a revoked state but loses BTC. This means that, with unidirectional payments, Bridge can never make profit by broadcasting a revoked state.

If Gateway chooses to stay online (or simply is online), then it will automatically punish Bridge as that is the way the LN protocol works. Punishing ends the game at this node and Gateway gets all of Bridge’s money in the broadcast state which is BTC. Thus, Bridge completes the game with zero payoff. The IoT ends up with amount of BTC and Gateway obtains a total of BTC. Here, there is no further rational action from the Gateway such as sharing a portion of its payoff with Bridge since . In other words, since both the Gateway and Bridge lost money, there is no possibility of them sharing funds between each other.

The LN Gateway Broadcasts a Revoked State: In this case, the revoked state is broadcast by the Gateway instead of the Bridge thus the tree-form slightly changes as shown in Fig. 9.

Fig. 9: Payoffs for Unidirectional Payments Case when Gateway Broadcasts a Revoked State

In the tree, the actions of Bridge and Gateway are swapped since revoked state is broadcast by the Gateway instead of the Bridge. After Gateway broadcasts an old state, if Bridge is offline; the game ends at this terminal node with the payoffs , , assuming that the Gateway broadcasts the same old state the Bridge broadcast in the previous case. Here, similar to the previous case, Gateway loses BTC and Bridge loses BTC. This also means that, with unidirectional payments, Gateway can never make profit by broadcasting a revoked state.

If Bridge chooses to be online and punish the Gateway, the Gateway loses its BTC in the old state to Bridge. Thus, the new payoffs become , , . However, since both the Gateway and Bridge lose money, i.e., and ; no further action from either of them is possible.

6.1.2 Equilibrium Analysis

Corollary 1: In a unidirectional payment case where Bridge broadcasts a revoked state, the Nash equilibrium is “open channel” for IoT; “close channel normally” for Bridge and “online & punish” for Gateway. When Gateway broadcasts a revoked state, the Nash equilibrium is “open channel” for IoT; “close channel normally” for Gateway and “online & punish” for Bridge.
Proof of Corollary 1: Using the backward induction, Gateway chooses to stay online and punish Bridge since as long as which is the case except for the first channel state in which the IoT holds all the channel funds. In that case, and payoffs for both choices are the same for Gateway. Thus, it can be concluded that in all cases, Gateway chooses to punish Bridge. When it comes to Bridge, its optimal choice would be to close the channel normally because . This is also in line with the fact that Bridge cannot make profit by broadcasting revoked states to the blockchain as mentioned earlier. Finally, it can be easily seen that the IoT chooses to open a channel since . Hence, the Nash equilibrium indicates that broadcasting a revoked state for Bridge is not an optimal choice because it cannot profit out of this action. Furthermore, in the case of getting punished by the Gateway, it will lose all its money which will completely ruin its objective of profit (payoff) maximization.

In case of Gateway broadcasting a revoked state, optimal choice for Bridge is to be online and punish the Gateway since as long as which is the case except for the first channel state. When we examine Gateway’s actions, its optimal move is to close the channel normally since . For the IoT device, it chooses to open a channel as not opening results in zero payoff.

This final result also completes the proof of the corollary which indicates that; for unidirectional payments, there is no benefit in attempting to steal any funds via revoked states even if this is done in collusion with other parties.

6.2 Bidirectional Payments

A good example use case of bidirectional payments in IoT micro-payments context is sensor data exchange. IoT devices can exchange sensor data among themselves or with data customers where they send/receive payments, thus performing bidirectional payments. In the next section, the game model for bidirectional payments is presented.

6.2.1 The Game Model

The Bridge LN Node Broadcasts a Revoked State: The game theoretical model is very similar to the unidirectional case. The main difference is that now, Bridge can possibly profit from broadcasting revoked states thus, it will have a second decision node later in the game. The extensive form is shown in Fig. 10.

Fig. 10: Payoffs for Bidirectional Payments Case when Bridge Broadcasts a Revoked State

The difference between the two versions starts at Gateway’s first decision node. At this node, the payoffs are different than that of the unidirectional case. If Gateway plays to be offline, game ends at this terminal node and the new payoffs become for IoT, for Bridge and for Gateway. Here, we focused on the case where Bridge makes profit from broadcasting a revoked state, which implies either of these 3 possibilities: 1) only IoT loses money, 2) only Gateway loses money, 3) both IoT and Gateway lose money. We know that, for the unidirectional payments, Gateway always has less funds in the old channel states. For the bidirectional case however, Gateway either has less funds or the same amount of funds in the old states, i.e., . This is because, Gateway does not charge fees when IoT receives payments which might cause it to have the same amount of funds in some states. Thus, can be rewritten as where is the small amount of BTC the Gateway loses. Similarly, can be written as where is the amount of BTC the IoT loses. Consequently, will be equal to . Here, depending on the broadcast state, either or can be equal to zero, but not both at the same time. When the game ends at this terminal node, it implies that Bridge successfully broadcasts a revoked state and makes BTC.

If Gateway is online (or chooses to stay online), it automatically punishes the Bridge and gets all the funds the Bridge has in the old state which is BTC. As a result, Gateway ends up with and Bridge with 0 (zero) BTC. We mentioned at Section 5.2 that the Bridge is selected by the IoT. This means that the Gateway does not necessarily know the Bridge and a collusion between them is not guaranteed. As a result, in its second decision node, Gateway decides on whether to share some of its profit with the Bridge or not. When Gateway plays to share some of its profit with the Bridge, the end payoffs of the players become: , , for IoT, Bridge, and Gateway respectively. Here, is the share rate of the collusion profits between Bridge and Gateway and . Otherwise, when Gateway plays not to share, the game ends with the payoffs: , 0, for IoT, Bridge, and Gateway respectively.

The LN Gateway Broadcasts a Revoked State: In this case, the tree-form changes as shown in Fig. 11.

Fig. 11: Payoffs for Bidirectional Payments Case when Gateway Broadcasts a Revoked State

The main difference is that the roles of Gateway and Bridge are swapped. In other words, since this time the Gateway is broadcasting a revoked state, other actions are decided by the Bridge. Normally, the Gateway is not incentivized to broadcast an old state since it has less or equal amount of funds in the old states. Only motivation to do it would be to collude with Bridge to steal money from the IoT. However, as mentioned in the previous case, a collusion is not guaranteed as the Bridge is chosen by the IoT. Nevertheless, the Gateway can still proceed and broadcast an old state in which the Bridge has more funds than it has in the most recent state. In this direction, the Gateway can broadcast the same old state the Bridge broadcast in the previous case. After Gateway broadcasts, if Bridge chooses to be offline, the game ends at this terminal node with the payoffs , , . This implies that the Gateway successfully broadcasts a revoked state losing BTC where .

If Bridge chooses to be online and punish the Gateway, it gets Gateway’s BTC from the old state. This means that Bridge now has BTC and Gateway has 0 (zero) BTC. After punishing, similar to the previous case, Bridge chooses to either share its profits with the Gateway or not. If Bridge plays to share, the endgame payoffs become , , . If Bridge chooses not to share, then the game ends with the payoffs: , , . Here, the that the Bridge uses can be different than the Gateway used for the previous case which totally depends on the choice of the Bridge.

6.2.2 Equilibrium Analysis

Corollary 2: In a bidirectional payment case where Bridge broadcasts a revoked state, the Nash equilibrium is “open channel” for IoT; “close channel normally” for Bridge and “online & punish”, “does not share” for the Gateway. When Gateway broadcasts a revoked state, the Nash equilibrium is “open channel” for IoT; “close channel normally” for Gateway and “online & punish”, “does not share” for the Bridge.

Proof of Corollary 2: For the proof of Bridge broadcasting a revoked state, we apply the backward induction and check Gateway’s payoffs at the end subgame (its second decision node) as seen in Fig. 10. At this node, Gateway chooses not to share profits since . Once we continue with the backward induction, we observe that Gateway plays to stay online and punish the Bridge as the same inequality holds. Similarly, Bridge obtains a better payoff if it plays to close the channel normally because . Finally, IoT chooses to open a channel as an optimal action since . Hence, it implies that the optimal solution for this game is that IoT chooses “open channel”, Bridge chooses “close channel normally”, Gateway chooses “online & punish” and “does not share”. That is, when IoT opens a channel, Bridge chooses to close the channel normally. In the event that Bridge chooses to broadcast a revoked state, Gateway plays to stay online and punish the Bridge. After that the optimal solution suggests that Gateway does not share the profits with the Bridge. This equilibrium implies that the Bridge will not broadcast a revoked state as it results in Gateway getting all its funds and not share anything back. Thus, the Bridge will always close the channel normally which never adversely affects the IoT’s funds.

In the case of Gateway broadcasting a revoked state, again we apply the backward induction and check Bridge’s payoffs at the end subgame. At this node, Bridge chooses not to share its profits since . Continuing with the backward induction, we observe that Bridge plays to stay online and punish the Gateway as the same inequality holds. Here, Gateway obtains a better payoff if it plays to close the channel normally because . Finally, IoT chooses to open a channel as . Thus, we conclude that the optimal solution for this game is that IoT chooses “open channel”, Gateway chooses “close channel normally”, Bridge chooses “online & punish” and “does not share”. That is, when IoT opens a channel, Gateway chooses to close the channel normally. In the event that Gateway chooses to broadcast a revoked state, Bridge plays to stay online and punish the Gateway. After that the optimal solution suggests that Bridge does not share the profits with the Gateway. This equilibrium implies that the Gateway will not broadcast a revoked state as it results in Bridge getting all its funds and not share anything back. Thus, the Gateway will always close the channel normally which never adversely affects the IoT’s funds. Note that for both cases, by having the IoT to choose the Bridge, we already removed the possibility that the Bridge and Gateway will be controlled by the same person. This final result also completes the proof of the corollary.

7 Evaluation

This section describes the experiment setup to implement the proposed approach and presents the performance results.

7.1 Experiment Setup and Metrics

To evaluate the proposed protocol, we implemented it by modifying the source code of c-lightning v0.9.3 [clightning] which is one of the implementations of the LN protocol written in C. The hsmd and bitcoin modules of c-lightning were modified. The hsmd module manages the cryptographic operations and controls the funds in the channel. As the name suggests, the bitcoin module handles the Bitcoin script, signature and transaction routines. Specifically, we thresholdized the funding_pubkey and the associated Bitcoin private key as explained in Section 5.2. To the best of our knowledge, this is the first-ever work that implemented threshold cryptography for LN. Our implementation is publicly available in our GitHub repository at https://github.com/startimeahmet/lightning.

In the experiments, we used WiFi (IEEE 802.11n) and Bluetooth 5.0 as the main communication protocol between the IoT device and the LN gateway. The purpose of performing the experiments with both WiFi and Bluetooth is to investigate how different wireless technologies perform with our approach. Thus, it is essential for the rest of the components of the experiment setup to stay the same while changing the wireless communication method. In this direction, we created two experiment setups that we will call WiFi setup and Bluetooth setup.

Both setups use a Raspberry Pi 4 Model B as the IoT device which is equipped with on-board dual-band IEEE 802.11b/g/n/ac wireless and Bluetooth 5.0. For the LN gateway, we used a desktop computer with Intel(R) Xeon(R) CPU E5-2603 v4 and 16 GB of RAM. The desktop computer was connected to the Internet through a Gigabit Ethernet connection inside Florida International University campus. It ran our modified version of the c-lightning for the full LN node. For the full Bitcoin node, it ran bitcoind [bitcoind] which is one of the most widely used implementations of the Bitcoin protocol. For the threshold operations, we used a slightly modified version of Gotham city [gothamcity] which is a decentralized client/server Bitcoin wallet application that utilizes 2-party threshold ECDSA. Gotham city consists of Gotham client and Gotham server. Gotham client is the wallet application and was run on the desktop machine. Gotham server is a RESTful web service acting as a server for the threshold operations and was run the Raspberry Pi. The other way is also possible (server on the desktop machine, client on the Pi) but it was easier to run the server on the Pi in our setup. Additionally, we created another LN node running the original c-lightning v0.9.3 on an AWS instance in Virginia. This node was used to perform the key send experiments.

For the WiFi setup, we connected a TP-Link TL-WN722N 150Mpbs Wireless USB Adapter to the desktop machine. Using this adapter, we shared the Ethernet connection of the desktop as a WiFi hotspot which Raspberry Pi connected to. In this way, the Pi directly communicated with the desktop machine over the WiFi (IEEE 802.11n) connection.

For the Bluetooth setup, since the desktop machine did not have any Bluetooth device by default, we connected an Asus USB-BT500 Bluetooth 5.0 USB Adapter to the desktop machine. Now, even though both devices have Bluetooth 5.0 connectivity, they cannot perform the threshold operations over Bluetooth as the Gotham city is designed to work over TCP/IP. To overcome this issue, we enabled TCP/IP to work over Bluetooth on the desktop machine. A bunch of configuration had to be done for this to work such as installing bluez package, creating a Personal Area Network (PAN) between the Pi and the desktop machine and more. Photos of the the experiment setup can be seen in Fig. 12 and 13.

Fig. 12: The desktop machine with both the WiFi and Bluetooth USB adapters connected.
Fig. 13: Raspberry Pi 4.

To assess the performance of our protocol, we used the following metrics: 1) Time which refers to the total communication and computational delays of the proposed protocol; 2) Cost which refers to the total monetary costs associated with opening channels, sending & receiving payments, and closing channels using the LN gateway; 3) Bandwidth which refers to the network usage of the IoT device and the required bandwidth (data rate) for the IoT device for timely LN operations.

To compare our approach to a baseline, we considered the case where the LN gateway performs the LN operations by itself such as sending and receiving a payment. In other words, no IoT device is present, and all LN tasks are solely performed by the LN gateway. We will refer to it as no IoT case in the next sections.

7.2 Communication and Computational Delays

We first assessed the computational and communication delays of our proposed protocol. Computational overhead of running the protocol on the Raspberry Pi involves 3 different computations. These are the AES encryption of the protocol messages, HMAC calculations and (2,2)-threshold computations. We used Python’s pycrypto library to encrypt the protocol messages with AES-256 encryption. The encrypted data size for the messages was 24 bytes. For the authentication of the messages, we used HMAC. To calculate the HMACs, hmac module in Python was used. To get the pure computation time of (2,2)-threshold key generation and signing, we used localhost for the server so that there is no real network traffic involved. We present these measured computation times at Table I. All values are an average of 10 runs of the respective operation.

AES HMAC (2,2)-Threshold (2,2)-Threshold
Encryption Calculation Key Generation Signing
15 ms 1 ms 2.4 s 320 ms
TABLE I: Computation Times on the IoT Device
from to WiFi Delay Bluetooth Delay No IoT Delay
Channel Opening LNGate OpenNode 5.3 s 5.8 s 3.58 s
Channel Closing LNGate OpenNode 4.01 s 5.47 s 1.41 s
Sending Invoice Payment LNGate eclair 4.48 s 4.92 s 3.86 s
Sending Key Send Payment LNGate YELLOWROUTE 6.24 s 8.66 s 3.73 s
Receiving Key Send Payment YELLOWROUTE LNGate 1.97 s 2.43 s 1.35 s
TABLE II: Execution Times of Various LN Operations for “WiFi”, “Bluetooth” and “No IoT” Cases

As can be seen from the results, the overhead of the AES encryption and HMAC calculation is negligible. (2,2)-threshold key generation takes about 2.4 seconds but it is not critical for LN operations as it is done 1-time at channel opening as explained in Section 5.2. The (2,2)-threshold signing time is only 320 ms which is again almost negligible.

We then measured the execution time of our protocol for 5 different LN operations using WiFi and Bluetooth as the communication method between the Pi and the desktop machine. The 5 LN operation we considered are: 1) Channel opening, 2) Channel closing, 3) Sending an invoice payment, 4) Sending a key send payment, 5) Receiving a key send payment. Execution time of an LN operation can be broken down to the pure execution time of the LN operation at the LN gateway plus the execution time of the (2,2)-threshold operation between the IoT device and the LN gateway. The results are presented in Table II and they are used in other experiments to evaluate the timeliness of the protocol.

The ‘from’ and ‘to’ fields in the Table II are the LN node aliases. For example, row 1 of the Table II should be interpreted as follows: A channel was opened from the node with alias LNGate to the node with alias OpenNode. The nodes OpenNode and eclair are public LN nodes on Bitcoin’s Testnet. LNGate is our node with threshold modifications which is located in Florida. YELLOWROUTE is another node we created that uses original LN software and is located in Virginia. Each delay value in Table II is an average of 5 execution of the respective LN operation.

As can be seen from the Table II, no IoT case is quicker compared to the WiFi and Bluetooth cases, as expected. The difference in delays is around 2 seconds for most LN operations which is introduced by the threshold operations performed between the IoT device and the LN gateway. It was already shown in Table I that, the computational delays for threshold operations were not significant. Then this tells us that, the extra delays are the communication delays of the threshold operations between the IoT device and the LN gateway. Note that, the channel opening and channel closing delays do not include the confirmation times on the blockchain. Receiving key send payments was the quickest LN operation to perform. On the other hand, sending key send payments took the most time to perform. Sending invoice payments were quicker compared to sending key send payments which could be due to the path the payments took.

It is clear to see from the results at Table II that, our protocol introduce only minor increase in delays. In particular for the WiFi case, invoice payment delay is very close to the no IoT case. We can also see that the WiFi is about %10-%30 faster than the Bluetooth. The reason that Bluetooth can keep up very well with WiFi in our experiments is that we enabled TCP/IP communication over Bluetooth. Without a setup like this, Bluetooth would most likely be considerably slower than WiFi and impractical to be used for an IoT micro-payment application. Nevertheless, a delay of 8.66 seconds to send a key send payment can be considered fast enough for most scenarios.

7.3 Cost Analysis

We consider and analyze the following costs associated with our proposed protocol: 1) The on-chain fees for channel opening and closing; 2) The fees that are charged by the LN gateway for IoT device’s payments; 3) Forwarding fees that are charged by the nodes on a payment route (i.e., bridge LN node).

According to our experiment results; a channel opening transaction signed with (2,2)-threshold ECDSA, incurs a fee of 222 satoshi when it is desired for the transaction to be included in the next block666See this channel opening transaction which is signed using (2,2)-threshold ECDSA: https://blockstream.info/testnet/tx/20739b2f5ce19e806a8b1fbe151924c643c8abb28cd635e372d0d7c253a09a57. Similarly, a unilateral channel close signed with (2,2)-threshold ECDSA, costs 183 satoshi777See this unilateral channel closing transaction signed with (2,2)-threshold ECDSA: https://blockstream.info/testnet/tx/f23bb92a6decb6bd05eff5907af30294bf0025ef776d53dad906b8d7950e9395. At current Bitcoin price of $38,500, these fees correspond to 8.5 cents and 7 cents respectively which are basically negligible considering these operations are 1-time.

LN gateway’s service fee for payments entirely depends on the LN gateway’s choice. In Section 7.5, we simulate this cost for a toll payment scenario. Forwarding fees again entirely depend on nodes’ choices which are on a payment path. In LN, nodes charge a fixed fee each time they route a payment which is called the base fee [lnroutingfees]. There is also fee per satoshi that nodes charge proportional to the satoshi value of the payment they route [lnroutingfees]. To measure an approximate value for the forwarding fee, we sent 10 LN payments using different routes for each. The average of the forwarding fees was 2 satoshi which is again negligible.

Most importantly; the channel opening, channel closing, and forwarding fees do not change with the introduction of (2,2)-threshold ECDSA. These values we measured are exactly the same for a regular LN node running the original LN software. Therefore, our protocol does not bring extra cost overhead for the LN operations.

7.4 Network Usage and Bandwidth Analysis

In this experiment, we investigate: 1) the network usage of the IoT device; 2) the required bandwidth for the IoT device to timely complete the LN operations with the LN gateway. To measure the network usage, we used Wireshark packet analyzer software. We captured the packets on a specific network interface, e.g., wlxec086b180e1b for WiFi, pan0 for Bluetooth. After the capture, using the endpoint statistics of Wireshark, we collected the number of packets and bytes information. We considered the same 5 LN operations which are: 1) Channel opening, 2) Channel closing, 3) Sending an invoice payment, 4) Sending a key send payment, 5) Receiving a key send payment. All LN operations were performed 5 times and the average values were calculated.

The network usage of WiFi and Bluetooth cases were the same and it ranged between (16,000, 130,000) bytes where (80, 600) network packets were exchanged between the IoT device and the LN gateway. The most network intensive operation was sending key send payments and the rest of the LN operations were more or less the same in terms of network usage.

Now, the required bandwidth for the IoT device can be calculated. If we focus on sending key send payments where the IoT device exchange around 130,000 bytes in 6.24 seconds (Table II), then the required bandwidth is 167 kbps. This is a reasonable bandwidth requirement considering that even the low-power wireless technology 6LoWPAN supports a data rate of 250 kbps [rfc6282].

7.5 Toll Payment Use Case Evaluation

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. Then, the LN gateway immediately sends the requested amount of payment to the toll company’s LN node. After the payment is successfully sent, a PaymentSendSuccess message is sent back to the car through the IoT gateway. For this to work, whole payment sending process must be completed before the car gets out of the communication range of the toll gate’s wireless system.

We know from Table II that, when WiFi is used, sending payments with our proposed protocol takes 4.48 seconds and 6.24 seconds for invoice and key send payments respectively. Assuming that the toll gate uses IEEE 802.11n for the wireless communication, then the communication range will be 250 meters which is the advertised range of 802.11n [matsumoto2009performance]. If cars pass through the toll gate with a speed of 70 miles per hour, there is around 8 seconds available for them to complete the protocol message exchanges with the LN gateway for a successful toll payment. Since payment sending times for both the invoice and key send payments are below 8 seconds, cars will be able to pay the toll on time. In the case of Bluetooth 5.0, the advertised range is around 220 meters [karvonen2019experimental] so the cars have around 7 seconds to pay for the toll. Again, from Table II, we can see that the invoice payments take 4.92 seconds and key send payments take 8.66 seconds for Bluetooth case. This means that the cars can pay the toll if the toll is paid via invoice payments. If not and cars have to send key send payments, then they would have to pass the toll gate with a lower speed; e.g, 50 mph.

We now investigate the cost of using this service for a car for 1 month where it makes 2 toll payments in a day for the sake of a complete analysis of the use case scenario. 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 toll amount is $0.75 per pass, then the service fee is $0.0375 per payment. In 1 month, the car will make 60 toll payments, so the total amount of service fees the LN gateway will be charging is only $2.25. Considering the convenience of making near-instant toll payments directly from a car, we believe paying an extra $2.25 in a month would be insignificant to the customers.

8 Limitations

Our proposed protocol requires changes to the LN protocol. Specifically, we propose changes to LN’s signing mechanism and commitment transactions. This will require ensuring that the updated LN software should be run on the Gateway and Bridge nodes in order to be able to support the IoT device transactions.

Additionally, our protocol requires the IoT device to be online for receiving payments. In an ideal setting, IoT device should be able to receive a payment even when it is offline. It is important to note that this is also a problem for LN in general [offlinelnnodes].

9 Conclusion

In this paper, we proposed a secure and efficient protocol for enabling IoT devices to use Bitcoin’s LN for sending and receiving payments. By introducing (2,2)-threshold scheme to LN and modifying LN’s existing peer protocol for channel management and commitment transactions, a third peer (i.e., IoT device) was added to the LN channels. The purpose was to enable resource-constrained IoT devices that normally cannot interact with LN to interact with it and perform micro-payments with other users. IoT device’s interactions with LN are achieved through an untrusted gateway node that has access to LN and thus can provide LN services in return for a fee. A game theoretic security analysis was provided to prove that the IoT device does not lose money when other channel peers attempt to cheat. Our evaluation results showed that the proposed protocol enables timely payments for IoT devices with negligible delay, cost and networking overheads.

Acknowledgments

We would like to thank Christian Decker for helping us better understand how some LN protocols work.

References