Page 72 - 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

IoT Device LN Gateway Bridge LN Node Node
LN
1. SendPayment
{Type: SendPayment, gateway generates its own signature as well and sends
Amount, Destination Node ID} these two signatures to the bridge LN node in a commit‑
2. Adds an HTLC output
to bridge's commitment ment_signed message (#6.2 in Fig. 6). The bridge LN node
and deducts a fee
(amount, destination node ID) checks the correctness of the signatures and once it veri‑
3. update_add_htlc ies that the signatures are valid, it replies to the LN gate‑
4. SignTxRequest way with a revoke_and_ack message (#7 in Fig. 6). This
{Type: SignTxRequest,
Commitment Transaction} message includes the commitment secret of the old com‑
5.1 Generates the signature mitment transaction effectively revoking the old channel
5.2 TxSigned state.
{Type: TxSigned, Signature}
6.1 Generates the signature Payment Sending Finalization: Now, the LN gateway
6.2 commitment_signed can also apply the changes to its own commitment trans‑
7. revoke_and_ack action. To notify the IoT device of the successful payment,
8. Applies the changes the LN gateway sends a PaymentSuccess message (#9 in
to its commitment
Fig. 6) to the IoT device which inalizes the payment send‑
9. PaymentSuccess
ing process.
Fig. 6 – Protocol steps for sending a payment. Messages in red show the
default messages in BOLT #2. 5.3 Channel closing process

IoT Payment Sending Request: The IoT device sends a We brie ly mentioned LN’s channel closing mechanism in
SendPayment message to the LN gateway to request a pay‑ Section 3.3.1. An LN channel can be closed: 1) unilaterally
ment sending (#1 in Fig. 6). This message has the follow‑ when one of the channel parties broadcasts its most re‑
ing ields: Type: SendPayment, Amount, Destination Node cent commitment transaction or 2) mutually where chan‑
ID. Here, we assume that the IoT device receives the des‑ nel parties agree on the closing fee and create and broad‑
tination node ID in some form (i.e. QR code) from the ser‑ cast a closing transaction. In our case, all 3 parties of the
vice provider (i.e. toll company). channel namely; the IoT device, the LN gateway and the
bridge LN node can close the channel. We explain each
Payment Processing at the LN Gateway: Upon receiving
case separately below:
the request from the IoT device, the LN gateway adds an
HTLC output to the bridge LN node’s commitment trans‑
action. When preparing the HTLC, the LN gateway deducts 5.3.1 IoT device channel closure
a certain amount of fee from the real payment amount
To close the channel between the LN gateway and the
the IoT device wants to send to the destination LN node.
bridge LN node which was opened due to a request from
Therefore, the remaining Bitcoin is sent with the HTLC.
the IoT device, the IoT device follows the proposed pro‑
Then, to actually offer the HTLC, the LN gateway sends
tocol explained below, which is also shown in Fig. 7.
an update_add_htlc message to the bridge LN node (#3
in Fig. 6). As explained in Section 3, this HTLC can be IoT Channel Closing Request: The IoT device sends a
redeemed with the payment preimage. Destination node ChannelClosingRequest message to the LN gateway.
ID is embedded into the onion routing packet in the up‑
Mutual Close: The LN gateway can close the channel uni‑
date_add_htlc message. And the amount is also sent in this
laterally or mutually. For the mutual close case, irst, it
message.
sends a shutdown message to the bridge LN node to ini‑
Getting Signature from the IoT Device: Now, the LN tiate the closing. If there are no pending HTLCs in the
gateway can apply the changes to the bridge LN node’s channel, the bridge LN node replies with a shutdown mes‑
commitment transaction and get it ready for signing. As sage. Now, the LN gateway and the bridge LN node start
in the case of channel opening, two signatures are needed; negotiating on the channel closing fee. Basically, both
one from the LN gateway and one from the IoT device. parties offer each other a fee that they think is fair un‑
Thus, we propose the LN gateway requests a signature til they both agree on the same fee. Each offer is done
from the IoT device for the new commitment transac‑ through a closing_signed message which includes the of‑
tion. For this purpose, the LN gateway sends a SignTxRe‑ fering party’s signature and the offered fee amount. When
quest message (#4 in Fig. 6) to the IoT device which has the LN gateway and the bridge LN node eventually agree
the following ields: Type: SignTxRequest, Commitment on a fee, the resulting closing transaction will be broad‑
Transaction. The IoT device generates a signature for this cast by the LN gateway. Since the LN gateway only has the
commitment transaction and sends it to the LN gateway bridge LN node’s signature for this closing transaction, it
in a TxSigned message having the following ields: Type: needs to also get the IoT device’s signature before it can
TxSigned, Signature (#5.2 in Fig. 6). broadcast it. Thus, we propose the LN gateway to send a
ClosingTxRequest message to the IoT device which has the
following ields: Type: ClosingTxRequest, Closing Transac‑
tion. Upon receiving the request, the IoT device generates
a signature for the closing transaction and sends it to the

60 © International Telecommunication Union, 2021