External invoice registry

[joostjager]

The invoice registry is one area where flexibility can be really beneficial to users. Some examples:

• Stateless invoices
• Multi-destination invoices (fail over in case one node goes down)
• Pre-acceptance checks for spontaneous payments

Currently it isn't easy or fast to implement this functionality. The invoice registry code is relatively complex because of the many different code paths and changes need to land in a release first. Running a fork is often outside a node operator's comfort zone.

This issue is about adding the option to use lnd with an external invoice registry so that users can experiment more easily in this area and the path is opened up for alternative (open-source) registry implementations.

On the technical side, this doesn't look too difficult. The one important call that needs to be routed to an another process is:

NotifyExitHopHtlc(rHash lntypes.Hash,
	amtPaid lnwire.MilliSatoshi, expiry uint32, currentHeight int32,
	circuitKey channeldb.CircuitKey, hodlChan chan<- interface{},
	payload Payload) (HtlcResolution, error)

Implementation could be via a bidirectional grpc stream.

So far LND doesn't connect out to other processes besides the chain backend. It is a question if other processes calling in to lnd such as htlc interceptor, channel acceptor, etc, is always the best choice. Maybe configuring lnd with a grpc endpoint for the invoice registry could work too.

First goal could be to add the grpc api for the invoice registry and then create an external registry using the code that currently lives within lnd. It can be the 'reference implementation'.

[Roasbeef]

This is more or less already possible: make invoices to a node that uses a fake/virtual private hop, then use an HTLC interceptor to handle the settle/cancel logic.

[joostjager]

More or less indeed, apart from the links that currently exist between registry and the channel arbitrator (lookup invoice preimage) and registry and the incoming onchain resolver (also notifyexithop).

Would be interesting to figure out what - if anything - is missing to allow implementation of a functionally equivalent external invoice registry using the htlc resolver api.

[joostjager]

Issue for what could be missing: #6040

[joostjager]

LDK issue for inspiration: lightningdevkit/rust-lightning#1199

[xraid]

could the "RPC middleware interceptor" be used to add and update a adapter component that in turn could use a by operator chosen store ...

[xraid]

"Multi-destination invoices (fail over in case one node goes down)"

would need a --data <field populated in invoice with fallback PK>

where implementations receive would then update the registry store

[Roasbeef]

Would be interesting to figure out what - if anything - is missing to allow implementation of a functionally equivalent external invoice registry using the htlc resolver api.

So we have a working version of something pretty close to what you're describing in a staging environment. The only additional thing we were looking to do was allow a custom invoice db impl to be passed in when creating lnd initially, so that could be some other replicated data store.

We aim to eventually package/open-source it in some form, but want to get some production hours on it first to make sure the solution/architecture is sound (make sure all the relevant gaps are plugged, etc).

"Multi-destination invoices (fail over in case one node goes down)"
would need a --data

Yeah IMO that's the next step over (ideally listing multiple pubkeys, w/ maybe them all counter-signing each other?), since that would let you implement a "multi-cast" like system, which would allow a service to effectively mask downtime of the set of nodes (they'd disable the chans and the client would then deetect thta and tr to use one of the other nodes listed).

[joostjager]

So we have a working version of something pretty close to what you're describing in a staging environment. The only additional thing we were looking to do was allow a custom invoice db impl to be passed in when creating lnd initially, so that could be some other replicated data store.

You mean an actual externally running invoice registry that handles all incoming htlcs passed through via a grpc stream? In that case the external registry would also handle tasks like adding invoices, hodling invoices, reconstructing amp, etc.

The second sentence seems to suggest that the invoice registry still lives inside the lnd process, but uses a shared data store (with an external registry, there wouldn't be a reason to pass a data store for invoices into lnd?)

[xraid]

by having these building blocks would then also suggest -- i could have my now flapping pk in device instead go to "spa" while device idling ...

[xraid]

and i am a big fan of the "Real-time Liquidity Inventory Lockup" possibilities among loosely coupled clusters

[joostjager]

Multi-node receive PoC: #6175