Skip to content

Commit

Permalink
Merge pull request #133 from NYDIG-OSS/readme-update
Browse files Browse the repository at this point in the history
readme: add additional details
  • Loading branch information
joostjager authored May 26, 2023
2 parents e2c2a80 + 48224fc commit 70bafd0
Show file tree
Hide file tree
Showing 2 changed files with 57 additions and 5 deletions.
62 changes: 57 additions & 5 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,65 @@
# Lightning Multiplexer

This repository contains the code for the `lnmux` service. The problem that `lnmux` solves is fail-over for incoming Lightning payments. BOLT11 invoices are bound to a single node. If that node goes down, the invoice is no longer payable. The same is true for the node or its peers running out of inbound liquidity.
This repository contains the code for Lightning Multiplexer service, `lnmux` for short.

The problem that `lnmux` solves is fail-over for incoming Lightning payments. BOLT11 invoices are bound to a single node. If that node goes down, the invoice is no longer payable. The same is true for the node or its peers running out of inbound liquidity.

A typical solution is to set up multiple nodes. If invoice expiry durations are short and down time is planned, it is possible to gracefully spin down a node by waiting for all invoices generated by that node to reach a final state. During that time, new invoices should only be generated on the remaining nodes.

This however does not work for unexpected down time. An invoice that may have been passed on to the payer already becomes impossible to settle.

What `lnmux` allows you to do is set up a cluster of nodes where each of these nodes can settle any invoice. If a node is unable to accept payments for one of the reasons above, senders will still be able to pay the invoice via one of the other nodes.

Even with all nodes in the cluster available, it can be advantageous for the sender to have multiple routing options to better utilize liquidity and minimise fees. If needed, multi-part payments can be completed through more than one cluster node.

## Design

`lnmux` is a massively stripped down version of a full Lightning node, almost to the point that there is nothing left. It has no channels, no external network connections and it does not partake in p2p gossip. It does have its own node key for signing invoices and it is also able to decode onion packets. In this document, the term full node refers to a full Lightning node, not a full Bitcoin node.

The intended setup is a single instance of `lnmux` in conjunction with a number of full nodes.

Senders direct their payments to `lnmux` by its node key, routing through any of the full nodes. When one of the full nodes detects a payment that is to be forwarded to `lnmux`, an alternative processing flow is entered. Instead of trying to look up the outgoing channel (which doesn’t exist), the routing node contacts `lnmux` directly to obtain the preimage for this HTLC and then settles it immediately. The payment is short-circuited with the final hop being no more than a call to obtain the preimage.

If one of the full nodes goes down, senders will keep looking for alternative routes to reach `lnmux`. If full node A is down, they will try to reach `lnmux` via full node B. Full node B is also aware of `lnmux` and is therefore able to settle the payment too. This is what realises fail-over behaviour.

Because `lnmux` has no channels, it is impossible to broadcast its location in the network through Lightning P2P gossip. Senders will not know how to reach it. This is why `lnmux` invoices include route hints. Route hints describe a route from one or more publicly known nodes to the destination. In the case of the example above, there will be two route hints. One hinting a path from full node A to `lnmux` and another one hinting from full node B to `lnmux`.

It is worth noting that senders are not able to distinguish `lnmux` from any other private node.

## Implementation

Multiplexer takes over the invoice handling logic from LND completely and it has its own Postgres-based invoice database where it keeps track of the state of invoices. The invoice databases of the LND instances are no longer used.

Invoices are solely created by Multiplexer and signed with its node key. The LND nodes are not involved in the invoice creation process, other than their node keys being listed as route hints.

![](lnmux_diagram.png)

For the settlement of invoices, Multiplexer interfaces with LND on the HTLC level through the HTLC interceptor API. HTLCs that come in via the interceptor stream are inspected by Multiplexer. If an HTLC pays to a known invoice, a settle message containing the HTLC preimage is sent back to the node that accepted the HTLC. At that point, Multiplexer marks the invoice as settled in its database.

This mechanism works for multi-part payments too, even when the parts come in through different full nodes. Multi-part, multi-node payments allow the sender to utilise the full liquidity across all nodes for a single payment, improving reliability along a different dimension. More generally, and this also applies to single-part payments, they can choose a route through the node that is best for them and for example minimise the routing fee.

It is critically important that every HTLC is always passed on to Multiplexer for handling. This applies to both the onchain and the offchain resolution paths. Inconsistent behaviour can lead to loss of funds.

In the future, support for node implementations other than LND may be added. Using a mix of implementations further increases the resiliency of the system.

## Single point of failure

In this described setup, a full node is no longer a single point of failure for a payment. With Multiplexer though, a new single point of failure is introduced. So did we really gain anything? We think the answer to that question is yes.

The Multiplexer database itself can be replicated, so we don’t count it as being an additional single point of failure.

The logic contained in Multiplexer is limited. It tracks incoming HTLCs in memory and when a set of HTLCs is complete, the corresponding invoice in the database is marked as settled. There is far less that can go wrong compared to all the failure modes of a full Lightning node. If Multiplexer is running in a framework like Kubernetes and crashes, a new instance can be brought up automatically with minimal downtime.

One scenario that may be problematic is a bug in Multiplexer from which it cannot recover. In a more distributed setup, that bug may be present too, but may not get triggered on all instances. For the moment, we consider this an acceptable risk. But if needed, the code can be extended to support multiple instances.

## Extra Features

In addition to the functionality described above, `lnmux` offers the following extra features:

* Defining a routing policy for the virtual channels. This effectively comes down to letting the operator charge an inbound fee for payments that arrive at their cluster of nodes.

* Generated invoices are stateless. This means that invoices that are still in the open state are not stored in the database. Only once the connection application requests settlement, the invoice is written to disk. The advantage of this is that the resource footprint of an invoice is very small. An example use that would leverage this advantage is a high-traffic website that optimistically displays a lightning invoice on its home page. This avoids the typical extra click to generate an invoice leading to a better user experience.

## Running

For the setup, it is assumed that there are multiple LND nodes running with connections to the wider Lightning network and sufficient inbound liquidity. The minimally required version of lnd is v0.16.0-beta.
Expand All @@ -19,7 +73,7 @@ For the setup, it is assumed that there are multiple LND nodes running with conn
switches on persistent storage of the final htlc resolution, which is needed
to move an invoice in lnmux to its final state.

* Create a postgres database. Note that `lnmux` uses stateless invoices. This means that the database only contains settled invoices.
* Create a postgres database.

* Create a config file for `lnmuxd` named `lnmux.yml`. An [example](lnmux.yml.example) can be found in this repository. The config file contains the following elements:
* LND nodes configuration: TLS certificate, macaroon, address and pubkey. Pubkey is configured as a protection against unintentionally connecting to the wrong node.
Expand Down Expand Up @@ -93,7 +147,6 @@ For the setup, it is assumed that there are multiple LND nodes running with conn
Each time an invoice is accepted, you will receive a pair (hash , setID):
```json
Response contents:
{
"hash": "rCdcdDvpo7oqkO1Gkh1hikofseQpUZhgAIaw6gYXz7M=",
"setId": "J1q7YDvixChKrJjjP/yvv16KiQdpHqwW7gy8jqxDAvI="
Expand Down Expand Up @@ -145,8 +198,6 @@ can be enabled via the `DistributedLock` config group.

Note that only the states `accepted`, `settle requested` and `settled` are published to callers of the `SubscribeSingleInvoice` rpc. Lnmux isn't aware of open invoices because it is stateless.

The transition from `settle requested` to `settled` can be made more robust in the future. This transition is happening already, but not backed by an actual final settle event from lnd. See https://github.com/lightningnetwork/lnd/issues/6208.

## Docker Instructions

We provide a Dockerfile to launch lnmux using docker.
Expand Down Expand Up @@ -185,6 +236,7 @@ To do so, you can simply use `--mount`:

> ⚠️ Don't forget to add **before starting nodes connected to lnmux** (aka Alice and Bob):
> - `--requireinterceptor` to make sure all htlcs are intercepted
> - `--store-final-htlc-resolutions` to make sure all htlcs are intercepted
> - `--tlsextradomain=host.docker.internal` to add docker DSN to TLS certs (otherwise you can't connect from a docker container)
>
> If your nodes are already started, you will have to stop them, remove manually tls certs and then restart them.
Expand Down
Binary file added lnmux_diagram.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 70bafd0

Please sign in to comment.