Page 75 - ITU Journal Future and evolving technologies Volume 2 (2021), Issue 5 – Internet of Everything

ITU Journal on Future and Evolving Technologies, Volume 2 (2021), Issue 5

Commitment Tx (Held by Gateway) performing this step, the LN gateway cannot get a signa‑
Input Funding Transaction Outpoint, Bridge's Signature ture from the bridge LN node for its own version of the
to_IoT
commitment transaction. Therefore, it is apparent that
IoT's balance on the channel and it is immediately the LN gateway will not be able to complete a success‑
spendable by IoT
Amount: 4 BTC ful payment without getting a signature from the IoT de‑
to_remote vice. On the other hand, if we were to use LN’s original
Bridge's balance on the channel and it is immediately 2‑of‑2 multisignature channels in our system, the LN gate‑
spendable by bridge way could move the funds without needing a signature
Amount: 0 BTC
from the IoT device. Because, with a 2‑of‑2 multisigna‑
Offered HTLC
ture channel, the LN gateway could send its own signa‑
- Output for the HTLC payment and spendable by the
bridge if it knows the payment preimage R ture to the bridge LN node which would be enough for
or the bridge LN node to be able to spend its commitment
- IoT gets it back after block height w
Amount: 0.9 BTC transaction. Since the LN gateway cannot spend the IoT
to_local device’s funds in the channel at its own will, the IoT de‑
- Gateway's fees on the channel. It can spend this output vice’s funds are always protected and can be only spent
using its private key but have to wait k number of blocks when the IoT device provides its signature. Consequently,
or the usage of 3‑of‑3 multisignature channels protects the
- Bridge can spend this output immediately using its
revocation private key if the gateway cheated IoT device’s funds from getting unwillingly spent by the
Amount: 0.1 BTC LN gateway.
Fig. 8 – An illustration of the commitment transaction stored at the LN
gateway with the IoT output and the fee output modi ied (to_IoT and
to_local, respectively). This commitment transaction is generated af‑ 7. EVALUATION
ter the following events: A channel with 5 BTC capacity is opened; the
IoT device initiated a 1 BTC payment to a destination; the LN gateway In this section, we explain our experiment setup and
charged the IoT device a service fee of 0.1 BTC. present the performance results.

published old state, it might bene it the bridge LN node. 7.1 Experiment setup and metrics
However, this attempt will be successful only if the LN
gateway is of line during the attempt. This brings us back To evaluate the proposed protocol, we created a setup
to the being of line issue. Basically, it is the LN gateway’s where an IoT device connects to an LN gateway to send
responsibility to stay online and protect itself against this payments on the LN. To mimic the IoT device, we used a
attack. As this is a general LN issue, it is beyond the scope Raspberry Pi 3 Model B v1.2 and the LN gateway was set
of this paper. up on a desktop computer with an Intel(R Xeon(R CPU
E5‑2630 v4 and 32 GB of RAM. This desktop computer
6. SECURITY ANALYSIS was in a remote location different from that of Pi’s. For the
full Bitcoin node installation, we used bitcoind [30] which
is one of the implementations of the Bitcoin protocol. For
In this section, we present how the attacks mentioned in
Section 4.2 are mitigated in our approach. the LN node, we used lnd v0.11.0‑beta.rc1 from Lightning
Labs [20] which is a complete implementation of the LN
Threat 1: Revoked State Broadcasts: For the attack protocol. Python was used to implement the protocol.
where the LN gateway broadcasts a revoked state, our ap‑ We used IEEE 802.11n (WiFi and Bluetooth Low Energy
proach proposed punishing the LN gateway. Basically, the (BLE 4.0 to exchange protocol messages between the
LN gateway loses the service fees it collected on the chan‑ Raspberry Pi and the LN gateway. In the WiFi scenario, we
nel to bridge the LN node. With our punishment addi‑ created a server & client TCP socket application in Python.
tion, the LN gateway is disincentivized from broadcasting
With this, Raspberry Pi and the remote desktop computer
a revoked state. Additionally, we proposed a protection
communicated with each other. Raspberry Pi was con‑
mechanism for the IoT device’s funds on the channel. In
nected to the Internet through a regular Internet modem
this way, even when the bridge LN node catches the LN
which acted as the IoT gateway. For Bluetooth experi‑
gateway while cheating, the IoT device does not lose any
ments, we irst paired the Raspberry Pi and the Bluetooth
funds. The other cases where the parties might lose funds
adapter of the IoT gateway. We used a laptop computer
because of being of line are not handled as they are gen‑
as the IoT gateway which had a Bluetooth adapter. Us‑
eral LN issues that are not related to our protocol.
ing Python’s bluetooth library, Raspberry Pi and the lap‑
Threat 2: Spending IoT Device’s Funds: Using 3‑of‑ top computer communicated with each other. The laptop
3 multisignature channels secure the IoT device’s funds computer was programmed to talk to the LN gateway over
in the channel since the LN gateway cannot spend them the same TCP socket application that was set up. In both
without getting the IoT device’s cryptographic signature cases, the LN gateway used gRPC API [31] of lnd to com‑
irst. As shown in Fig. 6, the LN gateway sends the newly municate with the LN node that was running on it.
generated bridge LN node’s version of the commitment To assess the performance of our protocol, we used the
transaction to the IoT device for signing in step 4. Without following metrics: 1) Time which refers to the total

© International Telecommunication Union, 2021 63