Lightning Network Support in FIO

Intro

Lightning Network (LN) is a Bitcoin Layer 2 network which allows users to open payment channels between each other and exchange Bitcoin payments without the need to settle to Layer 1 on every transaction. Addressing in LN is accomplished via invoices in accordance with BOLT #11: Invoice Protocol for Lightning Payments.

An invoice is an encoded string (similar to a public address) sent from Payee to Payer outside of LN, e.g. via copy/paste or QR code scan and containing variety of data fields, including amount, channel information, expiration date, signature, secret, etc. The primary reason LN uses invoices is because a secret value has to be passed back and forth to ensure the last invoice between parties in channel is used when settling to Layer 1. This is also a reason why an invoice should not be reused.

Here’s an example of an invoice:

lnbc2500u1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqzpuaztrnwngzn3kdzw5hydlzf03qdgm2hdq27cqv3agm2awhz5se903vruatfhq77w3ls4evs3ch9zw97j25emudupq63nyw24cg27h2rspfj9srp

You can see decoded value here.

Support in FIO

Since FIO Protocol already supports an invoice, aka FIO Request, it appears logical that it could be used as a vehicle to send LN invoices between FIO Addresses.

Existing new_funds_request fields may be used:

  • payee_public_address may include the LN invoice string

  • amount may be left blank as LN invoice already contains amount

  • chain_code = BTC

  • token_code = LNBC

  • memo may be left blank as LN invoice already contains memo

This will make 139 characters available for LN invoice. Unfortunately this is not sufficient for most LN invoices. This means that the current FIO Request structure does not support LN invoices.

Propose a FIP which will increase the allowed size of FIO Request content field and would consider the following:

https://fioprotocol.atlassian.net/browse/WP-604

The current FIO Request data type is String, so no data migration will be required.