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

3.3.1 BOLT #2: Peer protocol for channel SegWit: Segregated Witness (SegWit) was a Bitcoin soft‑
management fork that became active in 2017. It ixed the transaction
malleability problem. Before SegWit, it was possible to
This protocol [26] explains how LN nodes handle chan‑ change the transaction ID (txid) of a transaction after it
nel related operations thus called the peer protocol for was created. Eliminating malleability also enabled de‑
channel management. An LN channel has three phases ploying LN onto Bitcoin.
which are channel establishment, normal operation, and P2WSH: Pay‑to‑Witness‑Script‑Hash (P2WSH) is a type
channel closing. We propose modi ications to this proto‑ of Bitcoin transaction that uses SegWit. Before SegWit
col to incorporate the IoT device in channel operations. upgrade, Bitcoin was using Pay‑to‑Script‑Hash (P2SH)
High‑level explanations related to each channel phase are transactions.
given below.
Witness: It is the part of a SegWit transaction that is not in‑
Channel Establishment: To establish a channel, the fund‑ cluded when the transaction is hashed and signed. Thus,
ing node irst sends an open_channel message to the witness does not affect the txid.
fundee, who replies with an accept_channel message. Witness Script: This is the script that describes the condi‑
Then, the funder creates the funding and the commitment tions to spend a P2WSH output.
transactions. It signs the fundee’s commitment trans‑
action and sends the signature to the fundee in a fund‑ Bitcoin Opcodes: Operation codes (opcodes) specify the
ing_created message. The fundee also sends its signa‑ commands to be performed in computer languages. For
ture to the funder in a funding_signed message. Then, Bitcoin, its scripting language has a number of opcodes
that de ine various functions. For instance, OP_CHECKSIG
the funder broadcasts the funding transaction to open the
channel which becomes usable after exchanging the fund‑ checks whether a signature is valid.
ing_locked messages. Now, we brie ly explain LN’s Bitcoin transactions below
as speci ied by BOLT #3.
Normal Operation: Now that the channel is opened, it
can be used to send/receive payments. Both nodes can Funding Transaction Output: This is a P2WSH out‑
offer each other HTLCs with update_add_htlc messages. put with a witness script: 2 <pubkey1> <pubkey2> 2
The sender of the payment irst updates the commitment OP_CHECKMULTISIG. It sends the funds to a 2‑of‑2 mul‑
transaction of the receiver, signs it, and sends the sig‑ tisignature address which is generated from pubkey1 and
nature in a commitment_signed message. Receiving the pubkey2. pubkey is also referred to as funding_pubkey.
signature, the receiver applies the changes and sends a Commitment Transaction Outputs: A commitment trans‑
revoke_and_ack message to the sender to revoke the old action currently can have up to 6 types of outputs. These
state. Finally, the sender also applies the changes to its outputs are:
own commitment transaction which completes the pay‑
ment. 1. to_local Output: This P2WSH output is for the funds
of the owner of the commitment transaction and it
Channel Close: Both nodes can close the channel when is timelocked using OP_CHECKSEQUENCEVERIFY. It can
they want. To initiate a mutual channel closing, one of also be claimed immediately by the remote node if it
the nodes sends a shutdown message which is replied by knows the revocation private key.
a shutdown message by the counterparty. This means no
new HTLCs are going to be accepted. Then, the nodes 2. to_remote Output: This P2WPKH output is for the
start negotiating on a channel closing fee through clos‑ funds of the remote node which is immediately spend‑
ing_signed messages until they both agree on the same able by him/her.
fee. Once negotiated, the mutually agreed channel clos‑ 3. to_local_anchor and to_remote_anchor Output:
ing transaction is broadcast to the Bitcoin network and This P2WSH output was recently added to prevent
the channel is closed. Nodes can also choose to close a cases where the commitment transaction cannot be
channel by broadcasting their latest commitment trans‑ mined by miners due to icient fees. With this
action. However, this is not the preferred way to close a non‑timelocked output which both nodes can spend,
channel in LN and is only recommended to be done when the commitment transaction’s fee can be changed for
the counterparty is not responding. faster mining.
4. Offered HTLC Outputs: This is a P2WSH output for the
3.3.2 BOLT #3: Bitcoin transaction and script HTLCs that are offered to the remote node. It either
sends the funds to the HTLC‑timeout transaction after
formats
the HTLC timeouts or to the remote node that can claim
the funds using the payment preimage or the revoca‑
This speci ication [27] explains the format of LN’s Bitcoin
tion key.
on‑chain transactions. Following this protocol is essential
as it ensures that the generated signatures are valid. The 5. Received HTLC Outputs: This is a P2WSH output for
transactions that are speci ied in this protocol are: 1) the the HTLCs that are received from the remote node.
funding transaction, 2) the commitment transactions and The remote node can claim the funds after the HTLC
3) the HTLC transactions. Before explaining them, we irst timeouts or by using the revocation key or; the funds
describe some terminology related to Bitcoin. are sent to an HTLC-success transaction which can be
claimed by the local node with the payment preimage.

© International Telecommunication Union, 2021 57