Avoid adding all private channels with the same peer as hop hints in new invoices

[alexbosworth]

Background

When a node has multiple private channels with the same peer, the hop hints in their payment requests will be populated with multiple channels. The purpose of these hop hints is to specify the next node's key and indicate the fees and cltv delta needed for route construction.

In pathfinding, due to non-strict forwarding, an LND node paying to this destination will only use the maximal policy values across these multiple hinted channels.

Since it only uses the maximal policy values in order to be an acceptable forward over any channel, the creator of the invoice may as well save some space in the payment request by pre-calculating the maximal policy values and compressing multiple private channels with the same peer into a single set of edge policy values

Your environment

• LND 0.11.0-beta.rc2

Steps to reproduce

• Create multiple private channels to a peer
• Add a new invoice that includes private channel hop hints

Expected behavior

• Hop hints should only include a single pairwise hint

Actual behavior

• Hop hints includes the entire set of private channels

[kingonly]

This is critical when displaying an invoice in QR code.
"Busier" QR code is much harder to scan.

[ellemouton]

currently having a go at this issue 🤞

[carlaKC]

Chatted to @ellemouton about this offline a bit about the amount to set for the maximal policy hop hint that we create.

When LND is pathfinding, it interprets a hop hint's amount as the capacity of the channel, and we have no knowledge of the other private channels (unless it's a single hop payment, ignoring that case).

• If we set the cumulative balance of all our private channels, pathfinding will try to dispatch a HTLC that is larger than the actual private channel's capacity. And I don't think splitting will help us because we wouldn't sent 2 HTLCs with amount x/2 over a channel if a HTLC with some amount x just failed?
• If we set the capacity of our largest private channel with the peer, the payer will never send more than this amount through that peer (which could cause problems in the mobile case where it seems likely that one would have 2x private channels with one peer)

Alternatively, we could add enough hop hints per peer to make up some portion of the full invoice amount. @alexbosworth any wisdom?

[alexbosworth]

Splitting is an interesting case, yeah maybe in the case of splitting being necessary it is justified to include multiple channels

When LND is pathfinding, it interprets a hop hint's amount as the capacity of the channel, and we have no knowledge of the other private channels (unless it's a single hop payment, ignoring that case).

What is the hop hint amount? Here are the fields I see for hop hints:

pubkey (264 bits)
short_channel_id (64 bits)
fee_base_msat (32 bits, big-endian)
fee_proportional_millionths (32 bits, big-endian)
cltv_expiry_delta (16 bits, big-endian)

[carlaKC]

What is the hop hint amount? Here are the fields I see for hop hints

Ah nvm was looking at bandwidth hints in the router but those are from mission control rather than the hint itself.

[alexbosworth]

What is the hop hint amount? Here are the fields I see for hop hints

Ah nvm was looking at bandwidth hints in the router but those are from mission control rather than the hint itself.

I'm not sure why max htlc isn't included in those hints, that could help a lot with splitting