Technical proposal
Our proposal comes in two parts a full lightning node implementation based on the
lightning RFC also
referred to as BOLT (Basis of Lightning Technology),
an implementation which is compatible with the Bitcoin network and the Stratis network (a multi-chain
lightning node).
The second part is about the applications of lightning that use the lightning node
implementation such as swaps, watchtowers
and routing services which will be targeting cloud provides or the Stratis master nodes.
Lightning Node
The following sections describe the BOLTs we will implement that are required to run a lightning
node.
It also includes a docker based test suite to test and insure compatibility between existing
implementations.
The node will be compatible with the popular UI for lightning called RTL (Ride The Lightning)
All the BOLT codebase will come in the form of nuget packages, this are lightning library components
that can be used in C# applications such as web, mobile and even games (with unity).
Work has already started on an implementation called Lyn (lightning in Danish).
The codebase can be found here Lyn
The lightning node adds scaling capabilities to the already wide Stratis technology stack, we will
develop
the node with cloud architecture in mind, parts of the workload required to successfully route
payments in lighting
can be delegated to dedicated cloud service providers or master nodes.
Payment Channels (BOLT1,2,3,5,8,9)
Payment channels allow the exchange of transactions between two participants which are sending
payments
off-chain in a trustless setup.
This include a node that can create funding transactions to open channels, the commitment
transaction
to secure the funds and the HTLCs (hash timed locked outputs) to make off chain payments between
participants.
It also includes lots of boilerplate components such as the gossip messages, noise protocol the
interaction with base layer etc..
A big part of this section is already implemented (BOLT1,3,8,9) in the Lyn repo.
Payment Routing (BOLT4,11)
Onion routing (built of layers like an onion) refer to the ability to route payments between
participants who don't share a channel directly,
an onion routed packet is used to route a payment from an origin node to a final node through a
number of intermediate nodes, called hops.
The payment initiator node, who knows the public keys of each intermediate, create the onion packet
in such a way that each node only knows
it's previous and next route but can't read information of any participant or how many hope this
route has.
Invoicing, defining protocol messages where participants can request payments over Lightning.
Payment Channel Discovery (BOLT7,10)
Node and channel discovery serve two different purposes, Node discovery allows nodes to broadcast
information about themselves, so that other
nodes can open connections and establish payment channels with them. Channel discovery allows the
creation and maintenance of a local
view of the network's topology, so that a node can discover routes to desired destinations.
Discovery is done using gossip messages, each node that receives gossip messages stores it and
routes
it on to its peers.
Lightning Applications
Features that use and build on top of the lightning node and are intended to be used by Stratis
master
nodes
Atomic Cross-Chain Lighting Swaps
Lightning enables channel rebalancing using atomic swaps between an off-chain lightning channel
to a Bitcoin
on-chain address (and reverse) using a protocol extension called submarine swaps.
LBTC to STRAX swaps -
We'll use the submarine swaps protocol to enable atomic swaps between LBTC (Bitcoin locked in
lightning channels)
to STRAX on the stratis main chain.
LBTC to LSTRAX swaps -
A lightning protocol extension called HODL invoices introduces expirable hash locked lightning
payments, where
a routed lightning payment is locked for a certain time until a secret is revealed.
Using this mechanism a lightning payment from one chain can be hash locked at the receiver until
the lighting
swap payment from the sender on the second chain is sent.
Swaps will come with a light weight lightning UI.
Master node swap services
Stratis master nodes can provide a swap matching service where users can register a request to
make a swap or ask for
available open swaps, effectively becoming a non-custodial market liquidity provider.
When a swap will take place it will be routed using the master node channels and will incur
routing and swapping fees.
Stratis master nodes are known, semi-trusted, entities however the swap users can stay unknown.
Master nodes that run a swap service will gain fees in BTC and STRAX and will be required to run
a fullnode and a lightning
node on the Bitcoin and Stratis main chain.
Master node watchtower services
Watchtowers are specialized services that are always online in order to monitor the blockchain
for channel breaches
on behalf of lightning network participants.
Lightning channels create asymmetric commitment transactions on each side of the channel when
sending funds off-chain,
every new commitment transaction effectively invalidates all previous commitment transactions.
A malicious side of the channel who breach the channel can be punished by loosing all the funds in
the channel.
In order to spot channel breaches node operator must stay online to monitor the blockchain.
The services of monitoring a channel breach can be delegated to master nodes who keep an always
online node anyway.
A lightning user that is not always online and uses a watchtower service will register an
encrypted justice transaction alongside a
transaction locator to the Watchtowers. Both the encryption key and the transaction locator are
derived from the breach transaction id,
meaning that the Watchtower will be able to decrypt the justice transaction only after the
corresponding breach is seen on the blockchain.
Master nodes that run a Watchtower service can claim fees for such a service either in BTC or
STRAX and will be required to run a fullnode
and a lightning node of the network they provides watchtower services for.
Master node routing services
Lighting nodes build payment routes in order to make a payment over several hopes.
To be able to construct routes a node needs to maintain a recent and correct view of the network
channels and balances.
This is done using gossip messages that are sent over the lighting network.
Nodes stay online and continuously listen to gossip messages to be able to create a graph of the
network.
The services of constructing payment routes can be delegated to master who keep an always online
node anyway.
This enables light wallets that don't need to stay online to make route requests when making a
lightning payment.
Master nodes that run a routing service can claim fees for such a service either in BTC or STRAX
and will be required to run a fullnode
and a lightning node of the network they provides routing services for.
Routing services have some privacy disadvantages, to overcome that we can use Trampoline
payments
which are a proposed type of payment where the spender routes the payment to an intermediate
node
who can select the rest of the path to the final receiver or to another Trampoline enabled node.
Time permitting we may enable Master nodes to act as nodes that can route trampoline payments.