Multi-node receive [PoC]#6175
Closed
joostjager wants to merge 3 commits intolightningnetwork:masterfrom
Closed
Conversation
6646fe5 to
3d85d1c
Compare
3d85d1c to
5fc7127
Compare
5fc7127 to
8e36470
Compare
Contributor
Author
|
Closing as this is now implemented externally in https://github.com/bottlepay/lnmux |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is an exploration of the design space for multi-node receive.
The idea is to run a standalone process (working title:
invoice coordinator) that connects to a cluster of lnd nodes via the htlc interceptor API. The coordinator is backed by a replicated database that contains all invoices. It has its own node key and every invoice is generated by the coordinator. Invoices contain a hop hint for each node in the cluster with a dummy scid.When an htlc comes in on one of the cluster nodes, it is intercepted by the coordinator. The coordinator matches the hash with the invoice database and if there is one, it signals the lnd node to settle the htlc.
This allows invoices to be paid through any of the cluster nodes. When one node goes down, senders will retry with one of the other nodes listed in the route hints. Also shards of a multi-part payment may use multiple nodes.
Current implementation is an adaptation to LND. It allows LND to be run in a mode where it acts as the coordinator. To do that, the gateway node needs to be specified (only one supported atm):
lnd --gateway.pubkey=0314aaf9b2547682b81977b3ac0c5585c3521a0a5430fb410cb572d5c72364edf3 --gateway.tls=~/.lnd/tls.cert --gateway.mac=~/.lnd-bob/data/chain/bitcoin/regtest/admin.macaroon --gateway.host=localhost:10002What you can do with this is set up Alice and Bob with a channel between them and then connect the coordinator to Bob. This allows Alice to pay invoices created by the coordinator.
For production, it seems unlikely that we want to run a customized lnd as the coordinator. Instead the coordinator code can live in a fresh stand-alone repo. This also allows the database backend (
channeldb/invoices.go) to be re-implemented using structured sql.Dependencies: