Page 71 - 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 generated. The on‑chain transaction fee for this trans‑
action is deducted from the IoT device’s Bitcoin address
1. OpenChannelRequest since it requested the channel opening. As a next step, the
{Type: OpenChannel,
Channel Capacity} LN gateway creates the irst versions of the commitment
2. Connects to Bridge transactions for itself and the bridge LN node. Now, the
(channel capacity) LN gateway and the bridge LN node need to exchange sig‑
3. open_channel
natures for the newly created commitment transactions.
4. accept_channel Speci ically, the bridge LN node needs IoT device’s and LN
5. Creates the funding gateway’s signatures. Similarly, the LN gateway needs the
transaction and commitment
transactions. IoT funds the IoT device’s and bridge LN node’s signatures. The process
channel from its Bitcoin address
starts with the LN gateway asking for a signature from the
6. FundingSignatureRequest IoT device as explained next.
{Type: FundingSignatureRequest,
Channel Parameters}
Getting Signature from the IoT Device: The LN gate‑
7.1 Generates the signature
way now has to request a signature from the IoT device to
7.2 FundingSigned be sent to the bridge LN node in the funding_created mes‑
{Type: FundingSigned, Signature}
sage. For this, the IoT device needs the channel param‑
8. funding_created
eters that were agreed on earlier between the LN gate‑
9. funding_signed
way and the bridge LN node. Thus, the LN gateway sends
10. Broadcast the funding a FundingSignatureRequest message (#6 in Fig. 5) to the
tx to the Bitcoin network
IoT device having the following ields: Type: FundingSig‑
11. funding_locked
natureRequest, Channel Parameters. Having this informa‑
12. funding_locked
tion, the IoT device can generate the necessary signature
and send it to the LN gateway in a FundingSigned message
(#7.2 in Fig. 5) which has the following ields: Type: Fund‑
Fig. 5 – Protocol steps for opening a channel. Messages in red show the
default messages in BOLT #2. ingSigned, Signature.
Exchanging Signatures with the Bridge LN Node: Now
that the LN gateway has the IoT device’s signature, it can
Channel Opening Initiation: The LN gateway initiates
generate its own signature as well and send these two sig‑
the channel opening process upon receiving the request
natures to the bridge LN node in the funding_created mes‑
from the IoT device. For this, it connects to a bridge LN
sage (#8 in Fig. 5). This message also includes the funding
node which it selects from the existing LN nodes on the
transaction outpoint. Now, the bridge LN node is able to
network. Preferably, the LN gateway chooses a node with
generate the signature for the LN gateway’s commitment
many active channels to have good chances of getting the transaction and sends it to the LN gateway with the fund‑
IoT device’s payments routed to the destination LN node.
ing_signed message (#9 in Fig. 5). Note that, the LN gate‑
Upon establishing a connection, the LN gateway sends an
way does not have the IoT device’s signature for its own
open_channel message to the bridge LN node (#3 in Fig.
5). This message includes a parameter called the fund‑ commitment transaction yet. In case the bridge LN node
becomes unresponsive at this stage, the LN gateway can
ing_pubkey which is a Bitcoin public key. Both channel
ask the IoT device for its signature to close the channel
parties provide their own funding_pubkey which are later
unilaterally.
used to construct the multisignature address of the chan‑
nel. Here, we propose to add the funding_pubkey of the Broadcasting the Funding Transaction: Now is the
IoT device in open_channel message as well. Once the time for the LN gateway to broadcast the funding transac‑
bridge LN node receives this message, it responds with an tion to the Bitcoin network. After broadcasting the trans‑
accept_channel message (#4 in Fig. 5) to acknowledge the action, the LN gateway and the bridge LN node wait for the
channel opening request from the LN gateway. This mes‑ transaction to reach enough depth on the blockchain (typ‑
sage includes the funding_pubkey of the bridge LN node. ically 3). Once the required depth is reached, they send
funding_locked messages (#11‑12 in Fig. 5) to each other
Creating the Funding and Commitment Transactions:
to lock the channel and begin using it.
Exchanging these messages locks the channel parameters
and the LN gateway can now start creating the funding
transaction. Using the funding_pubkeys of all 3 parties, the 5.2 Sending a payment
LN gateway creates a 3‑of‑3 multisignature address which
As in the case of channel opening, the introduction of the
will be used to store the channel funds. Then, the LN gate‑
way creates a Bitcoin transaction from the IoT device’s IoT device requires modi ications to LN’s payment send‑
ing protocol as well. We incorporate the IoT device in the
Bitcoin address to the 3-of-3 multisignature address it
process for signature generation. The details of the pay‑
ment sending protocol are depicted in Fig. 6 and elabo‑
rated below:

© International Telecommunication Union, 2021 59