Do extra hop channels in a BOLT#11 invoice need to exist on chain?

Question

According to the BOLT#11 specification, a node may add extra routing information for private channels to an invoice, where they specify the public key of the penultimate hop, along with the short_channel_id.

r (3): data_length variable. One or more entries containing extra routing information for a private route; there may be more than one r field

• pubkey (264 bits)
• short_channel_id (64 bits)
• ...

However, unlike channels announced through a channel_announcement message, there are no signatures to prove that the invoice payee actually owns that channel, or even that it really exists. Technically, it appears that the invoice creator could point to any valid 2-of-2 UTXO on the chain and claim it to be their private channel.

Do existing implementations check whether the transaction referred to by the r field's short_channel_id actually exists on the blockchain and that they are valid 2-of-2 multisig transactions?

If not, could short_channel_id in the invoice r field be re-purposed to refer to some abstract account which the pubkey in the hop information has custody of (Such that the pubkey node unwraps the last onion packet himself and signs any messages with the private key associated with the account)?

A user sending a payment should not need to worry about whether the channel really exists, as long as they receive the payment from the node who owns pubkey.

Otherwise, if there are any potential risks, should the BOLT#11 specification also be modified to include a pair of signatures for the funding transaction which short_channel_id refers to?

Answer 1

What you propose is (theoretically) totally possible but as far as I understand (for a good reason: the short_channel_id would loose its semantics) not implemented.

The problem is as far as I understand that even the construction of private channels are currently implemented with a 2-2 multisig wallet. You could patch your lightning node though so that your private channels could operate on a different payment channel mechanism (or without an actual channel as an what you call it abstract channel)

Let us assume you have such an abstract channel after patching your lightning node: The sender who creates the payment would use the channels from the invoice to create the onion. In the onion the sender has to use the short_channel_ids that are given from the gossip protocol and from the invoice.

As far as I remember the code the node creating the invoice relies on the fact that the information from the gossip protocol and the invoice is correct and constructs the onion. In particular the existence of a private channel cannot be checked against the gossip store anyway. Also the nodes routing the payment don't know later hops anyway and don't care.

So only your nodes that run private channels who are actually forwarding the payment have to see if they know the channel (and they should if they mess around with the protocol. The channel does not even have to be backed on the blockchain in such a case)

However theoretically the sender could - when creating the onion - check if there is at least an output on the blockchain that is referenced by the short channel id and that the output is at least a 2-2 multisig wallet. However that would only be a a hint that this output belongs to a funding transaction of an actual payment channel. In general payment channels cannot be detected for certain from the blockchain data.

BTW: When I was tinkering about similar ideas I came up with the name virtual payment channels instead of your proposed name abstract payment channels. Meanwhile I believe the best way to construct virtual payment channel is by fetching the htlc of the first node in your private network. This can for example be done with a c-lightning plugin (which does not exist in an open source way) and can be used to scale a farm of lightning nodes for an HA service. ]

I recommend waiting until rendezvous routing from BOLT1.1 is implemented. With Rendezvous routing it will be very easy to construct private channels. You can create an onion with a rendez vous point outside of your private network and as soon as the onion enters your network the first node can catch the htlc and talk with the real recipient over any communication protocol to release the preimage.