LNGate: Secure Bidirectional IoT Micro-payments using Bitcoin’s Lightning Network and Threshold Cryptography*

BY KEYHUNTER 05.03.2025
LNGate: 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 attacks. We implemented the proposed protocol by changing LN’s source code and thoroughly evaluated its performance using several Raspberry Pis. Our evaluation results show that the protocol; is fast, does not bring extra cost overhead, can be run on low data rate wireless networks, is scalable and has negligible energy consumption overhead. To the best of our knowledge, this is the first work that implemented threshold cryptography in LN.

Index Terms—Lightning network, Bitcoin, threshold cryptography, Internet of things, micro-payments

1 INTRODUCTION

The last decade has witnessed a fast adoption of IoT in numerous domains as it provides great opportunities and convenience [2]. 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 [3]. Other potential micro-payment applications in this context include electric vehicle charging, parking payments, sensor data trading etc. [4], [5].

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, we argue that as seen with some existing applications [6], some users prefer cryptocurrency payments over traditional methods due to the privacy and anonymity advantages or simply due to personal choice and thus offering a cryptocurrency-based payment solution for IoT transactions is needed. Out of all cryptocurrencies, Bitcoin [7] has the biggest potential to be used for IoT micro-payments as it is the most commonly used cryptocurrency and dominate the market in terms of market capitalization. Specifically, out of all cryptocurrencies, its market cap is at around 50% [8]. Recent studies show that it became a viable option compared to credit card payments, especially in Asia [8]. Its current user base is more than 150 million [2]. This means that regardless of the debate around Bitcoin, there is a growing community out there which will continue to use it and thus, there will always be a need to cater to their needs in terms of research and development.

However; long confirmation times, low throughput, and high transaction fees have been the main concern in mainstream cryptocurrencies which limits their scalability [9] 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 [10]. As an example, Lightning Network (LN) [11] has been introduced as a PCN solution for Bitcoin. LN currently exceeds 16,000 nodes since its creation five years ago. In addition to addressing the scalability, latency and cost issues, LN also provides flexibility in terms of its reach. Specifically,

  1. https://coinmarketcap.com/
  2. https://blog.chainalysis.com/reports/bitcoin-addresses/

as long as one has at least one LN channel, s/he can make payments to any other LN nodes using the existing channels in the network as long as there is a multi-hop route. Despite these advantages, LN still cannot be run on most of the IoT devices because of the computation, communication, and storage requirements [12]. Specifically, using LN requires running an LN node along with a full Bitcoin node which in total, occupies more than 473 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 LN 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 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 several Raspberry Pis as IoT devices and a desktop computer as the LN gateway. We demonstrated that the proposed protocol 1) has negligible communication and computational delays thus enables timely payments; 2) is scalable for increasing number of IoT devices and payments; 3) can be run on networks with low bandwidth (data rate); and 4) associated energy consumption and monetary costs of using the protocol for IoT devices are negligible.

Contributions: Our contributions in this work are as follows:

  • We propose LNGate\textsuperscript{2}, 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 attacks.
  • We implemented LNGate\textsuperscript{2} 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 the 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.

2 Related Work

Hannon and Jin [13] 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 [14] 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 [15]. 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 (\mu)Raiden [16] whose development stopped more than 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. [17] 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 pay-ment 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. [18] 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. [19] 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. [20] 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 the routing performance of the protocol drops significantly when there are malicious nodes in the network. A slightly different work by Tapas et al. [21] 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 versions of LN such as Neutrino [22] light client and Phoenix [23] 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.

In addition to these works, we acknowledge that there are also many works that offer cash payments from IoT devices that do not include cryptocurrencies. These are typically bank-based, card-based and digital cash based payment options [24], [25]. However, as mentioned before, our goal is not to compete with these solutions. Our work is just a reliable and convenient alternative for those who prefer cryptocurrency payments that rely on blockchains.

Finally, we would like to note that this work is an extension of our conference paper [1] 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 attacks was not analyzed formally. In this journal version, we used game theory to formally analyze the collusion attacks 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. We also present completely new scalability and energy consumption experiments. 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 [11] and later was implemented and deployed onto Bitcoin Mainnet by Lightning Labs [26]. 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 [27]. The number of users using LN has grown significantly since its creation. At the time of writing this paper, LN incorporates 16,450 nodes and 74,625 channels which hold 5,438 BTC in total (worth around 160 million USD) [4]

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 (BOLT) 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 5 Bitcoins (BTC), she can send payments to Bob until her 10 BTC in the channel are exhausted.

The reverse of the funding transaction is called the closing transaction which is used to close an LN channel. It is also an on-chain transaction which needs to be broadcast to the Bitcoin network.

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.

Inputs to Alice’s commitment transaction is the funding transaction outpoint and Bob’s signature. Outpoint is the A 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. 1.

Hash Time Locked Contract (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, 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 new blocks are mined. Output 3 in Fig. 1 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 protect Bob from a possible cheating attempt by 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 numbers. 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 in LN which does not involve such preparation is called key send. With this method, senders do not need to contact the recipients or have an invoice first to send payments.

Note that as long as there is at least one channel to LN, one may be able to reach all other LN nodes since LN enables multi-hop payment forwarding. This means one does not need to open an LN channel with every node it wants to exchange 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 [28].

3.2 Threshold Cryptography

Threshold cryptography [29] 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 [30]. In a threshold scheme, a secret is shared among ( n ) parties and a threshold ( t ) is defined such that, no group of ( t – 1 ) can learn anything about the secret. Such setup is defined as ((t, n))-threshold scheme. We utilize (2,2)-threshold cryptography in our proposed protocol for cooperative signing and key generation. The (2,2)-threshold schemes we used in this work are the same as the ones we used in our preliminary work [1]. We just provide the details of the Elliptic Curve Digital Signature Algorithm (ECDSA) which is used by Bitcoin for its signing operations.

ECDSA Signature Scheme

ECDSA signature scheme takes an input message ( m ) and a private key ( x ) and produces a pair of integers ((r, s)) as output. The steps of the algorithm are as follows:

  1. Hash ( h = H(m) ) of the message is calculated. ( H ) is a hash function (i.e., SHA-256).
  2. A secure random integer ( k ) between ([1, n-1]) is generated.
  3. A random point ((x, y) = k \cdot G ) is calculated. Then, ( r = (x \mod n) ) is computed.
  4. Signature proof ( s = k^{-1} \cdot (h + r \cdot x) \mod n ) is calculated.
  5. ((r, s)) is returned which is the ECDSA signature.

3.3 Game Theory Background

In this paper, the concept of subgame perfect equilibrium (SPE) [31] 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

https://github.com/lightningnetwork/lnd/pull/3795

https://github.com/lightning/bolts/blob/master/11-payment-encoding.md

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.

To find the solution of a game with a similar setting (i.e., SPE), the concept called backward induction [32] 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 [33] 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. 2. Illustration of the system model.

4 System 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. 2. We also show other tools and intermediary devices; Threshold client, LN gateway’s LN and Bitcoin nodes, Threshold server. IoT device wants to pay the receiver LN node for the goods/services. IoT device 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. We assume that the owner of the IoT device also operates the device for these transactions. Any third party operation of the IoT devices is also possible but this may raise business privacy issues among the owner and the operator which is beyond the scope of this work. 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 the 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 assume that the communication between the IoT device and the LN gateway is secured using TLS-like mechanisms. Based on our system model and application, possible adversaries to the system are the LN gateway and the bridge LN node which are assumed to be malicious. Therefore, we consider the attacks that would potentially be performed by these actors as well as the ones related to the specific processes of our payment application for the IoT devices. For instance, we assume that, both of these actors can be selfish in the sense that they can send old channel states to the Bitcoin blockchain in an attempt to cheat. We also assume that the LN gateway and the bridge LN node can collude with each other for deceiving the IoT devices. Furthermore, these nodes can also deviate from the proposed protocol descriptions to make monetary benefits.

Note that there may be also external attacks to Bitcoin’s consensus mechanism and transactions independent from our approach i.e., not specific to our application. For instance, 51% attack enables external adversaries to gain control of the blockchain [34]. Similarly, double spending attack tries to enable spending of the same currency at least two times [35]. There are also attacks to LN by congesting the channels or the layer-1 [36], [37]. Since mitigations to these…

known attacks are already analyzed in previous studies [38], [39] or in the same papers where the attacks are proposed (e.g., for LN), we assume that our protocol will not be impacted from these attacks. Based on these assumptions, we consider the following attacks to our system:

  • Threat 1: Collusion Attacks: The LN gateway and the bridge LN node can collude with each other to steal money from the IoT device.
  • 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; 2) broadcasting revoked states and; 3) colluding with the bridge LN node.
  • Threat 3: Ransom Attacks: The LN gateway can deviate from the protocol after opening a channel for the IoT device and not execute IoT device’s requests (i.e., uncooperative LN gateway). Then, it can ask the IoT device to pay a ransom before executing the payment sending/receiving or channel closing operations.

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 transactions reflecting their balance. An illustration of LN’s original commitment transaction was given in Fig. 1.

Our proposed modified version of LN’s commitment transactions are shown in Fig. 3. 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 other outputs as the IoT device cannot be punished because of cheating attempts from other channel parties. This essentially protects IoT device’s funds in the channel. Apart from that, the LN gateway’s and the 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 the 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. 4. We explain the protocol step by step below:

  • IoT Channel Opening Request: IoT sends an OpenChannelRequest message (Message #1 in Fig. 4) 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 address 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.1. IoT device can make this choice by accessing API services that provide public LN information.
  • 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. 4). The funding_pubkey is a Bitcoin
  1. e.g., https://amboss.space/

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. 4) 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. 4) 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 transaction. At this step, the LN gateway also creates the commitment transactions for itself and the bridge LN node (#7 in Fig. 4). 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, thresholding 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 using a (2,2)-threshold child key derivation process (#6 in Fig. 4) also known as, 2P-HD [40]. 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. 4). 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 generate the signature in a (2,2)-threshold signing (#8 in Fig. 4). 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. 4). 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. 4).
  • 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. 4). 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).
  1. Custom 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.readthreedocs.io/lightning-openchannel_init.7.html

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. 4).

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. 5 and elaborated below:

  1. SendPayment {Type: SendPayment, Payment Amount, Destination Node ID}
  2. Adds an HTLC output to bridge’s commitment and charges service fee
  3. update_add_htlc (destination node ID, payment amount)
  4. Threshold Signing to generate signature
  5. commitment_signed
  6. revoke_and_ack
  7. commitment_signed
  8. Threshold 2P-HD for new commitment point
  9. revoke_and_ack
  10. update_fulfill_htlc
  11. commitment_signed
  12. Threshold 2P-HD for new commitment point
  13. revoke_and_ack
  14. Threshold Signing to generate signature
  15. commitment_signed
  16. revoke_and_ack
  17. PaymentSendSuccess

Payment Sending Initiation: To request a payment sending, IoT device sends a SendPayment message (#1 in Fig. 5) 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. 5). When preparing the HTLC, the LN gateway deducts a certain amount of fee from the real payment.

amount the 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. 5) to actually offer to the 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. 5 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. 5). 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. 5). 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. 5). 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. 5). Once this is done, the LN gateway sends the revoke_and_ack message (#9 in Fig. 5).
  • 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. 5) then a commitment_signed message (#11 in Fig. 5) 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. 5). After sending the revoke_and_ack message (#13 in Fig. 5), 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. 5) with the IoT device then sends the commitment_signed message (#15 in Fig. 5). Finally, the bridge LN node replies with a revoke_and_ack message to irrevocably fulfill the HTLC (#16 in Fig. 5).
  • 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. 5).

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 does not charge a service fee for receiving payments.

The steps of the proposed protocol is shown in Fig. 6 and explained in detail below:

  • 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. 6) 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. 6 for sim- plicity). At this stage, similar to the payment sending case, there are going to be two rounds of \textit{commitment_signed} and \textit{revoke_and_ack}. The bridge LN node initiates the first round by sending a \textit{commitment_signed} message to the LN gateway to commit the initial changes on the channel (#2 in Fig. 6). Here, before sending a \textit{revoke_and_ack} message, the LN gateway performs a threshold 2P-HD (#3 in Fig. 6) with the IoT device to thresholdize the next commit- ment point. Then, it sends the \textit{revoke_and_ack} message (#4 in Fig. 6). Now, the LN gateway needs to send a \textit{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. 6). Then, the \textit{commitment_signed} message is sent (#6 in Fig. 6) and a \textit{revoke_and_ack} message is received (#7 in Fig. 6) 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 \textit{commitment_signed} & \textit{revoke_and_ack} round. Thus, the LN gateway first sends an \textit{update_fulfill_htlc} message (#8 in Fig. 6). Then, the LN gateway and the IoT device generate a signature in a (2,2)-threshold signing (#9 in Fig. 6) which is sent to the bridge LN node in a \textit{commitment_signed} message (#10 in Fig. 6). Bridge LN node responds by first sending a \textit{revoke_and_ack} message (#11 in Fig. 6) then a \textit{commitment_signed} message (#12 in Fig. 6). Finally, be- fore sending the \textit{revoke_and_ack} message, the LN gateway again performs a threshold 2P-HD with the IoT device to thresholdize the next commitment point (#13 in Fig. 6). It then sends the \textit{revoke_and_ack} message (#14 in Fig. 6) 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 \textit{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 transac- tion 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.
  • IoT Device Channel Closing Request: The IoT device sends a \textit{ChannelClosingRequest} message to the LN gateway.
  • Mutual Close: The LN gateway has two options to close the channel which are \textit{unilateral} or \textit{mutual} close. In mutual close, the LN gateway and the bridge LN node first exchange \textit{shutdown} messages and then start negotiating on the channel closing fee. For this, they start exchanging \textit{closing_signed} messages. This message includes the offered fee and offering party’s signature. Thus, each time the LN gateway sends a \textit{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 gate- way just broadcasts its most recent commitment transac- tion to the Bitcoin network after getting it (2,2)-threshold signed with the IoT device. Once the broadcast transaction is mined, the channel is closed and everyone’s funds in the channel settle in their respective Bitcoin addresses.
  • 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 address.
  • 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:
  • LN Gateway Channel Closing Request: The LN gateway sends a \textit{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 address.
  • 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 \textit{closing_signed} messages. Since this re- dquires 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.
  • 5.5.4 Behavioral Analysis of Channel Closures
  • In our preliminary version of this work [1], the protocol was only capable of unidirectional payments. With unidi- rectional payments, the LN gateway and the bridge LN node cannot make profit by broadcasting revoked states or colluding with each other. However, enabling bidirectional payments where the IoT device can also receive payments from other nodes in LN requires revisiting the previous analysis. The problem is, if the IoT device receives a pay- ment, it will have some old states in which it has less money. Thus, the LN gateway or the bridge LN node can publish these old channel states to the blockchain to cheat and profit. To better illustrate these cases and have a formal analysis, 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.
  • Game Model: The game theoretical model in an extensive form, i.e., tree-form, is shown in Fig. 7 and set up as follows: There are two players in this game: The LN gateway (Gateway) and the bridge LN node (Bridge). Both the Gateway and Bridge can start the game.
  • With probability $p$, Bridge starts the game. So, at its first 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 $y$ BTC and $z$ BTC for Bridge and Gateway, respectively (i.e., $(y, z)$ BTC). Furthermore, we assume that the IoT device (IoT) will have $x$ BTC for this case. Here, we can write the following equation:
  • $$x + y + z = C$$
  • where $C$ is the channel balance.
  • If Bridge chooses to broadcast a revoked state, the Gateway gets to play at its first decision node in this game. At this node, normally Gateway will punish the Bridge as that is the way the LN protocol works. As explained before, if an LN node broadcasts an old state, its funds will be automatically swept by the counterparty. However, since we are examining the behavior where Gateway and Bridge are trying to steal funds from the IoT, there is a chance that Gateway will go offline before Bridge broadcasts the old state. Or, it might also happen that Gateway goes offline due to a power/Internet outage which Bridge can see and try to exploit. Thus, at this node, Gateway can either punish the Bridge or be offline.
  • If Gateway plays to punish the Bridge, Bridge’s funds in this old state will be taken by the Gateway as proposed in our protocol description in Section 5.1. If the channel balances of IoT, Bridge and Gateway are $(x’, y’, z’)$ BTC respectively in this old state, Gateway will have $z’ + y’$ BTC after punishing the Bridge. Here, we can write the following equations:
  • $$x’ + y’ + z’ = C$$ $$y’ > y$$ $$z’ \leq z$$ $$x’ < x$$
  • because we know that Bridge has more funds in the broadcast revoked state and Gateway either has the same amount of funds or less. Gateway cannot have more funds in an old state because its balance only increases when IoT sends payments. Gateway does not charge fees when IoT receives payments on the channel. Hence, the game ends at this terminal node with the payoffs $(0, z’ + y’)$ BTC.
  • If Gateway plays to go offline instead, Bridge will end up with some extra funds. Thus, the end game payoffs will be $(y’, z’)$ BTC.
  • Game can also be started by the Gateway with probability $1 – p$. Normally, Gateway does not have an incentive to broadcast a revoked state because it does not have any old states in which it has more funds. But, we still analyze it for the sake of completeness. In its decision node, Gateway decides to whether close the channel normally or broadcast an old state. If Gateway chooses to close the channel normally, the game ends at this terminal node with the same payoffs as before; $(y, z)$ BTC. If Gateway chooses to broadcast an old state where the channel balances are $(x”, y”, z”)$ BTC for IoT, Bridge and Gateway respectively, Bridge will have the options of whether to punish the Gateway or be offline. Here, similar as before, we can write the following equation:
  • $$x” + y” + z” = C$$
  • If Bridge plays to punish the Gateway, Gateway’s funds in this old state will be taken by Bridge as proposed in our protocol description in Section 5.1. Thus, Bridge will have $y” + z”$ BTC after punishing the Gateway. Here, we can write the following equations:
  • $$y” > y$$ $$z” \leq z$$ $$x” < x$$
  • One should note that, in this node, Gateway will get zero payoff. Thus, the game ends at this terminal node with the payoffs $(y’ + z’, 0)$ BTC.
  • If Bridge plays to be offline instead; unlike the previous scenario, Gateway will not end up with some extra funds. Instead, Bridge ends up with some extra funds. In that case, the end game payoffs will be $(y’, z”)$ BTC.
  • Equilibrium Analysis:
  • Theorem 1. In a simple behavioral game for channel closures where the Bridge plays first, the Nash equilibrium is “close channel normally” for the Bridge, and “punish” for the Gateway. Symmetrically, when the Gateway plays first, the Nash equilibrium is “close channel normally” for the Gateway, and “punish” for the Bridge.
  • Proof. For the proof of Bridge starting the game first, we apply the backward induction.

Useful information for enthusiasts:

Contact me via Telegram: @ExploitDarlenePRO