Page 74 - 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 Therefore, this situation should not result in any loss of
Transactions: There are no changes to the to_remote funds for the IoT device in possible cheating attempts by
outputs. The LN gateway’s to_remote output pays other channel parties. We examine the possible revoked
to the bridge LN node’s remotepubkey, the bridge LN state broadcast cases by the LN gateway and bridge LN
node’s to_remote output pays to the LN gateway’s node separately below and show how both cases are han‑
remotepubkey. dled properly.
Changes to Offered HTLC Outputs of the Commitment
5.5.1 Revoked state broadcast by the LN gate‑
Transactions: The witness script of this output nor‑
mally has OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 way
OP_CHECKMULTISIG which sends the funds to the lo‑
The LN gateway can broadcast revoked commitment
cal node with the HTLC‑timeout transaction. For the
transactions to the blockchain since they are already
LN gateway’s offered HTLC outputs, the local node is
signed by everyone. This attempt has 2 possible out‑
the IoT device instead of the LN gateway itself, thus
comes: 1) The bridge LN node was of line for long enough
local_htlcpubkey is changed to IoT_htlcpubkey. Our
to not realize the LN gateway was cheating. Thus, it loses
protocol does not support offered HTLC outputs for the
some or all of its funds in the channel depending on the
bridge LN node’s commitment transaction. This is be‑
broadcast old state. 2) The bridge LN node was online
cause our protocol only supports payments from the IoT
during the LN gateway’s cheating attempt thus, sweeps
device to destination LN nodes. This is a limitation which all the funds in the channel using the revocation private
we plan to address in the future.
key of the respective old state.
Changes to Received HTLC Outputs of the Commit‑ The irst scenario is the famous being of line issue for the
ment Transactions: The current design does not sup‑ LN nodes. All existing LN nodes are vulnerable to this at‑
port received HTLC outputs for the LN gateway’s commit‑ tack when they are of line for extended periods of time
ment transaction as the IoT device cannot receive pay‑ [28]. Therefore, it is not speci ic to our protocol and ad‑
3
ments on the channel. On the other hand, the bridge LN dressing it is beyond the scope of this paper .
node’s commitment transaction supports received HTLC However, the second scenario jeopardizes the IoT device’s
outputs and we do not propose any changes. funds if not addressed. To handle this case, we propose
Changes to HTLC‑Timeout and HTLC‑Success Trans‑ two modi ications to the LN gateway’s commitment trans‑
action. The irst modi ication is for the to_IoT output at
actions: As explained above, we do not support HTLC‑
which the IoT device’s funds are held. We propose that
success transactions for the LN gateway’s commitment
even after a failed cheating attempt by the LN gateway,
transaction as the IoT device cannot receive payment
the bridge LN node cannot spend the to_IoT output. In
on the channel. Similarly, HTLC‑timeout transactions
other words, we propose to make this output spendable
are not supported for the bridge LN node’s commit‑
only by the IoT device at all times. In this way, the IoT de‑
ment transaction. For the HTLC‑timeout transactions
vice’s funds in the channel will be protected. The second
in the LN gateway’s commitment transaction, we pro‑
pose having 3 signatures instead of 2. Thus, the new modi ication is proposed for the fee output (to_local)
transaction input witness will be: 0 <remotehtlcsig> of the LN gateway. Normally, this output is spendable by
the LN gateway only. We propose to turn it into a con‑
<localhtlcsig> <IoThtlcsig> <>. For the HTLC‑
ditional output such that, if the LN gateway gets caught
success transactions in the bridge LN node’s com‑
while cheating, the bridge LN node can spend this out‑
mitment transaction, we again propose having 3 sig‑
put using the revocation private key. In other words, the
natures instead of 2. The new transaction input
witness will be: 0 <remotehtlcsig> <IoThtlcsig> LN gateway will lose the fees it collected on the channel
if it gets caught while cheating. This modi ication disin‑
<localhtlcsig> <payment_preimage>. Additionally,
centivizes the LN gateway from attempting to cheat there‑
the local_delayedpubkey in the witness script for
fore addresses the revoked state broadcast issue. Conse‑
the output of the HTLC‑timeout transaction in the
quently, with these 2 modi ications, the IoT device’s funds
LN gateway’s commitment transaction is changed to
IoT_delayedpubkey. are protected and the LN gateway is disincentivized from
broadcasting revoked states. We illustrate the LN gate‑
way’s modi ied commitment transaction in Fig. 8.
5.5 Handling revoked state broadcasts
We brie ly mentioned in Section 3.2 that Alice and Bob can 5.5.2 Revoked state broadcast by the bridge LN
attempt to cheat by broadcasting revoked channel states node
to the blockchain. LN uses timelocks to address this is‑
Similar to the LN gateway, the bridge LN node can also
sue. The idea is not to let the broadcasting party spend its
broadcast its revoked commitment transactions to the
funds immediately while letting the counterparty do so.
blockchain in an attempt to cheat. Depending on the
Since we proposed changes to the LN protocol, it requires
revisiting the revoked state cases. Speci ically, the IoT de‑ 3 Watchtowers [29] were proposed to protect LN nodes against this
vice does not store any commitment transactions nor re‑ threat.
vocation keys. It is only involved in signing operations.
62 © International Telecommunication Union, 2021