LN Parser— Decoding and Encoding of Lightning Payment Request
LN(Lightning Network)Parser is a tool that helps in decoding and encoding of a lightning payment request in a human-readable format. In this article, we discuss how the decoder and encoder work in detail.
1. Decoding
Decoding is the process of converting a coded message to a readable form. The lightning network decoder is created by using the BOLT(Basis of Lightning Technology)#11 invoice protocol which is used for lightning payments. In LN Parser, we decode the encoded payment request of Bitcoin and other cryptos which are hard forked from Bitcoin. The decoded information is displayed on the Payment Information section upon decode.
1.1 Payment Information
The payment information of the decoded payment request has the following information.
The format for a Lightning invoice uses Bech32 encoding, which is already used for Bitcoin’s isolated witness. It can be simply reused for Lightning invoices even though its 6-character checksum is optimized for manual entry, which is unlikely to happen often given the length of Lightning invoices. Below are a few of the tags and its detail message for learning.
Coin-type — It refers to the various cryptocurrencies and its network type like Bitcoin, Bitcoin — Testnet, Bitcoin — Regtest, Litecoin, Litecoin — Testnet.
Millisatoshis — It is a multiplier which multiplies the value of satoshis by 0.001. The amount it equals is that, 1 BTC = 100,000,000,000 millisatoshis and 1 satoshis = 1,000 millisatoshis.
Prefix — This part refers to ln + BIP-0173 currency prefix (e.g. lnbc for Bitcoin mainnet, lntb for Bitcoin testnet, and lnbcrt for Bitcoin regtest).
Timestamp — The timestamp is set to the number of seconds since Midnight 1 January 1970, UTC in big-endian.
Signature — The signature must set to a valid 512-bit secp256k1 signature of the SHA-2 256-bit hash of the human-readable part, represented as UTF-8 bytes, concatenated with the data part (excluding the signature) with 0 bits appended to pad the data to the next byte boundary, with a trailing byte containing the recovery ID (0, 1, 2, or 3).
Tag — description — Short description of the purpose of payment (UTF-8) can be added, e.g. ‘1 cup of coffee’.
Expire_time — The expiry time is set in seconds (big-endian). The default is 3600 (1 hour) if not specified.
Routing_info — It contains, a. pubkey (264 bits) b. short_channel_id (64 bits) c. fee_base_msat (32 bits, big-endian) d. fee_proportional_millionths (32 bits, big-endian) e. cltv_expiry_delta (16 bits, big-endian).
The pubkey is the node ID of the start of the channel. The short_channel_id is the short channel ID field to identify the channel and fee_base_msat. The fee_proportional_millionths and cltv_expiry_delta are as specified in BOLT #7.
Payment_hash — The payment_hash to be set to the SHA2 256-bit hash of the payment_preimage that will be given in return for payment.
Example: lnbc2500u1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqzpuaztrnwngzn3kdzw5hydlzf03qdgm2hdq27cqv3agm2awhz5se903vruatfhq77w3ls4evs3ch9zw97j25emudupq63nyw24cg27h2rspfj9srp
Breakdown:
lnbc: prefix, Lightning on Bitcoin mainnet
2500u: amount (2500 micro-bitcoin)
1: Bech32 separator
pvjluez: timestamp (1496314658)
p: payment hash…
d: short description
- q5: data_length (q = 0, 5 = 20; 0 * 32 + 20 == 20)
- xysxxatsyp3k7enxv4js: ‘1 cup coffee’
x: expiry time
- qz: data_length (q = 0, z = 2; 0 * 32 + 2 == 2)
- pu: 60 seconds (p = 1, u = 28; 1 * 32 + 28 == 60)
signature: aztrnwngzn3kdzw5hydlzf03qdgm2hdq27cqv3agm2awhz5se903vruatfhq77w3ls4evs3ch9zw97j25emudupq63nyw24cg27h2rsp
fj9srp: Bech32 checksum
Signature breakdown:
- e89639ba6814e36689d4b91bf125f10351b55da057b00647a8dabaeb8a90c95f160f9d5a6e0f79d1fc2b964238b944e2fa4aa677c6f020d466472ab842bd750e hex of signature data (32-byte r, 32-byte s)
- 1 (int) recovery flag contained in signature
- 6c6e626332353030750b25fe64410d00004080c1014181c20240004080c1014181c20240004080c1014181c202404081a0a189031bab81031b7b33332b2818020f00 hex of data for signing (prefix + data after separator up to the start of the signature)
- 3cd6ef07744040556e01be64f68fd9e1565fb47d78c42308b1ee005aca5a0d86 hex of SHA256 of the preimage
1.2 Special features in LN Parser Decode
1.2.1 Recent Requests
We can find the last six recent request which has been decoded, in the LN Parser Decode. This recent requests can be also decoded from the recent request pannel.
1.2.2 Compare
In LN Parser Decode, we can also compare two requests from the recent requests panel which displays the comparison between the selected requests on the right side as compare — payment information.
1.2.3. QR code
In this feature, you can scan and get the lightning payment request from the decoded information.
2. Encoding
The LN Parser Encode is made to encode your testnet payment details like network type or coin-type, the number of satoshis, testnet private key and payment hash which will generate an encoded payment request which is shown on the right side of the screen.
Special features in LN Parser Encode
2.1 QR code
In this feature, you can scan and get the lightning payment request from the encoded information.
We created the LN Parser app to help users and developers understand lightning payments with ease. If you have any questions or suggestions or feedback reach out to us on https://twitter.com/slam_trade.
