# Non-Custodial Lightning @ MicroStrategy

## Purpose

This proposal aims to provide a rough design & approach by which MicroStrategy could provide enterprise-grade, cloud-based wallet & paywall lightning services without assuming custody of funds that belong to clients. Assuming custody of funds raises legal & regulatory concerns. This document proposes a way to potentially avoid those concerns without compromising the core functionality of the lightning services.

## Remote Signing

Lnd supports [remote signing](https://github.com/lightningnetwork/lnd/blob/master/docs/remote-signing.md), which allows for the lnd node's private keys to be separated from the node itself. In other words, a `watch only` lnd node is responsible for RPC, peer to peer communication, channel management, chain monitoring, and other key functions of a lightning node. On a separate machine, a `signer` lnd node operates in a limited mode whereby it only listens for signing requests from the `watch only` node and performs the requested signatures.

Private keys are generally considered to represent ownership of any bitcoin they control. If one has the private keys for a wallet containing 1 BTC, they are understood to own that 1 BTC.

By separating the private keys from all other functions of a lightning node, we can separate the aspect of custody of the funds belonging to a lightning node from the management and usage of that node.

## Architecture

Here we consider an architecture using the `signer` and `watch only` separation discussed above. Tenants 1, 2, and 3 are hypothetical MicroStrategy enterprise lightning customers using cloud-based services. MicroStrategy is a subscriber of its own service, with its own dedicated lnd node that does not use a remote signer as there are no concerns of 3rd party custody.

Within MicroStrategy's AWS are the custom Wall & Wallet services, LndHub or equivalent services to track end-user balances, all lnd nodes, and the gateway lightning node(s) that act as the intermediary between the various tenant nodes and the broader lightning network. The bitcoind node and postgresql databases shared by lnd nodes are not pictured.

Outside of MicroStrategy's environment are the `signer` nodes which hold the private keys for each respective tenant. These nodes are initialized and operated by the tenant themselves, and access to make signing requests is then granted to MicroStrategy. Ideally, these would exist within the same AWS region as MicroStrategy's services to facilitate networking, maximize reliability, and minimize latency.

MicroStrategy's custom Wall & Wallet services are unaware whether they are communicating with an lnd node that holds its own keys (as is the case with MicroStrategy's lnd node) or with an lnd node operating in watch-only mode (as is the case with non-custodial Tenant lnd nodes). Lightning payments and other functions work identically in either case. The only difference is where the private keys reside.

flowchart TB
    A1:[Tenant 1\nLnd Signer]
    A2:[Tenant 2\nLnd Signer]
    A3:[Tenant 3\nLnd Signer]

    style A1: fill:#ffffde
    style A2: fill:#ffffde
    style A3: fill:#ffffde
    
    A1:---->B1:
    A2:---->B2:
    A3:---->B3:

    subgraph MicroStrategy AWS Environment   
        B:[MicroStrategy\nLnd Node]     
        B1:[Tenant 1\nLnd Node]
        B2:[Tenant 2\nLnd Node]
        B3:[Tenant 3\nLnd Node]
        
        C:[MicroStrategy\nWallet &\nWall Service]
        C1:[Tenant 1\nWallet &\nWall Service]
        C2:[Tenant 2\nWallet &\nWall Service]
        C3:[Tenant 3\nWallet &\nWall Service]
        
        D:[MicroStrategy\nLndHub]
        D1:[Tenant 1\nLndHub]
        D2:[Tenant 1\nLndHub]
        D3:[Tenant 1\nLndHub]
        
        F:[MicroStrategy\nLightning\nGateway]
        
        C:-->D:
        C1:-->D1:
        C2:-->D2:
        C3:-->D3:
        
        D:-->B:
        D1:-->B1:
        D2:-->B2:
        D3:-->B3:
        
        B:-->F:
        B1:-->F:
        B2:-->F:
        B3:-->F:

        style B: fill:#FFFF33
        style B1: fill:#FFFF33
        style B2: fill:#FFFF33
        style B3: fill:#FFFF33

        style C: fill:#D9232E
        style C1: fill:#D9232E
        style C2: fill:#D9232E
        style C3: fill:#D9232E    
    end
    
    G:(((Lightning\nNetwork)))
            
    F:<-->G:(((Lightning\nNetwork)))

    style F: fill:#FFFF33
    style G: fill:#FFFF33

## Example Setup

Below is an example of rough steps needed to get a tenant setup for MicroStrategy's lightning services using their own private keys and remote signer node.

1. MicroStrategy sets up an lnd node with corresponding LndHub and Wall & Wallet services for tenant.
2. Tenant sets up an AWS EC2 instance using a provided image or container that will initialize an lnd node in remote signer mode and generate the public key and authentication data needed to make signing requests.
3. Tenant provides the generated data from step 2 along with the instance's IP address to MicroStrategy, and ensures that the instance can be reached by MicroStrategy.
4. MicroStrategy injects the tenant's data generated in step 2 into the environment set up in step 1 (e.g. as k8s secrets), ensures that the lnd node is functioning properly, and proceeds with on-boarding the tenant.

## Considerations

With remote signing, the final control of and lnd wallet's keys and any funds belonging to it remains with the tenant and not with MicroStrategy. However, for as long as the remote signer is accepting signing requests from MicroStrategy, MicroStrategy has the ability to spend those funds. This can be thought of as analogous to a bank account or credit card with authorized users on it besides the account owner, although the funds belong to the owner they can be spent by the authorized user up until access is revoked.

### Pros

- Virtually identical behavior of existing "custodial" set-up. MicroStrategy's services and code need not be modified whatsoever to accommodate lnd nodes running in watch only mode.
- Minimal intervention and technical expertise required by tenant. The remote signer can be run in a "set it and forget" mode with very little upkeep or maintenance required.
- The signer is effectively stateless, aside from the cryptographic seed used to initialize the wallet. This means that there's no major concern over data loss or retention.
- Signer can be stopped at any time by tenant unilaterally, and access to MicroStrategy can be revoked at any time.
- Funds can be recovered by tenant without requiring assistance from MicroStrategy - the steps for recovery can be provided upfront in a guide.

### Cons

- Potential for latency. Since the remote signer exists on a separate machine from the watch-only node that handles rpc requests and channel updates, there is an additional step requiring network I/O for each operation requiring a cryptographic signature. However, this latency can be minimized or nearly eliminated if the remote signer runs in the same AWS region as MicroStrategy's services.
- Tenant is responsible for backing up & securing the cryptographic seed for the wallet. This is a requirement for any non-custodial system, however, and we can provide assistance and some best practices for doing this.
- Lightning service will fail should remote signer go offline.
- MicroStrategy still has access to the funds on the node as long as the remote signer is actively signing requests - this means that a compromise within MicroStrategy could still result in loss of tenant funds.

## Alternatives

Below are the two main alternatives considered for a non-custodial approach to lightning.

### Tenants Run Own Nodes

In this approach, the tenant runs an entire lnd node themselves. MicroStrategy makes RPC requests to their node using credentials provided by the tenant, and connects the tenants' node to the rest of the lightning network via a gateway.

This sort of approach is facilitated by services like [Voltage](https://voltage.cloud/) and [LightSpark](https://www.lightspark.com/), which run lightning nodes on behalf of their customers in the cloud and give customers access to the nodes. Note that with such services, the private key material still exists on machines that are setup by the service provider.

The is similar to the remote signer approach discussed in this proposal, but it puts more infrastructure under the tenant's control. The set of pros & cons are similar - in both approaches MicroStrategy is granted access to the funds on the lnd node rather than actual ownership of the funds. However, running the entire full node introduces additional overhead, setup time, and operating costs on the tenant. Although some of this burden can be offloaded onto a third party cloud-based lightning node provider like Voltage or Lightspark, it does not seem like a worthwhile tradeoff.

### On-Prem

In this approach, the lnd node and the services using it is operated by the tenant. MicroStrategy would provide the code & configuration as well as a lightning gateway node. This is a significant departure from a cloud-based approach, and requires significant work to setup on behalf of the tenant.