Public key-based routing #4758
Public key-based routing #4758
Conversation
Roasbeef
added
enhancement
|
Something like this would also be really useful in the HTLC interception API as one would basically be able to generate random identifiers for themselves and/or other clients that may be behind them (similar to the hosted channels idea). |
There was a problem hiding this comment.
Small change, potentially large impact! I think we should also poll some end user wallet like Breez to see if they'd be interested in such a feature. For wallets like them that follow an LSP like model (so most of their users are connected directly to them) this has the potential to greatly improve the privacy of both them and their users. Otherwise it's possible someone could prob invoices to examine the set of short channel IDs listed, even if they're random and/or rotated somewhat.
| } | ||
| targetPeerKey = targetLink.Peer().PubKey() | ||
| } else { | ||
| targetPeerKey = *packet.nextHopPubKey |
There was a problem hiding this comment.
The system is ready and waiting for this feature 😎
| ChannelID: channel.ShortChanID().ToUint64(), | ||
| NodeID: channel.IdentityPub, | ||
| // Zeroed out for privacy reasons. | ||
| // ChannelID: channel.ShortChanID().ToUint64(), |
There was a problem hiding this comment.
Assume in final form, we'd also need to actually extend the invoices themselves to signal to the sender that they need to be able to support pubkey routing.
There was a problem hiding this comment.
Yes, that is currently signaled implicitly by one or more zero channel ids in the route hints. It would also be nice to reduce the invoice size (and qr codes) by removing the eight zero bytes completely.
|
Also I think one of the reasons we didn't do this in the past was that with the old onion format the overhead would've been |
The proposal in this PR is to leave out the channel id completely. I think what you're suggesting is a workaround for a world without pubkey routing? The downside is that there needs to be some coordination between routing node and final hop as to which obfuscating mapping for the channel ids is being used.
I never questioned really why we didn't do it before, but that reason makes sense for sure. Small correction: the new TLV onion overhead only applies to the second last hop (and possibly preceding ones for multi-hop hints), not the final one. |
|
Pubkey routing was discussed in yesterday's lightning-dev IRC meeting. One important thing for receivers to be aware of is that senders on an old version are not able to construct hop payloads with the new pubkey field in it. Their invoices are not backwards compatible (at least the hop hint part of it). It would require a new flag on the I think that it is better to not zero out the scids in the hop hints, but to populate them with the truncated pubkey of the next hop. Then in the switch forwarding logic implement a three way switch:
Routing nodes that signal pubkey routing will also recognize the truncated pubkeys. That way invoices remain backwards compatible and can be used regardless of the sender version of the node software. Receivers of course still only include new style hop hints for peers that signal support for it. When a sufficiently large portion of the network has updated, the scid can be removed from the invoice and routing can rely on just the new pubkey tlv field. |
|
Could also be useful if the output index of a batch channel creation ever overflows a uint16 in the future |
|
@joostjager, remember to re-request review from reviewers when ready |
I've proposed lightning/bolts#814 on
lightning-rfc. Summary:Would the
lndteam be open to accepting a PR implementing this for the0.13release?Rough working code below to show areas of impact. Missing is the feature bit and using that to select the routing mode for hop hints during invoice creation.