ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-05 📝 Original message: Good morning Rusty, On ...

📅 Original date posted:2018-11-05
📝 Original message:
Good morning Rusty,

On Monday, November 5, 2018 8:26 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:

> CJP cjp at ultimatestunts.nl writes:
>
> > > Looking through BOLT 4, the text assumes inherently that source
> > > routing is done, and even has a shared secret between hop and
> > > source.  However, it may be possible in rendezvous routing to simply
> > > provide the blinding key (while hiding everything beyond the first
> > > hop on the destination half of the route).
> >
> > Sounds like it makes sense; I need to look into it.
>
> Here's my attempt to design a "merchant forward" service using stuff we
> have today.
>
> Alice wants to remain anonymous, even from the lightning network. Bob's
> node offers a forwarding service. Alice pays Bob (base + percentage?),
> gives a path Bob->Alice, and Bob gives Alice a short-channel-id
> (BobAliceSCID) and privkey to use (BobAliceSecretKey). Anything sent
> from Bob to this short channel id and pubkey is in fact forwarded via a
> new HTLC to Alice.
>
> Alice identity BobAliceKey to create an invoice, with a route-hint to
> say pubkey=Bob, short_channel_id=BobAliceSCID. Alice can sign
> that invoice, and Bob can decode the incoming payment, from which it
> creates a new HTLC to pay Alice. The payer doesn't even know this
> arrangement exists: it looks exactly like Alice has a private channel
> with Bob.
>
> The minor downside: because we conflate invoice keys (Alice needs) and
> onion keys (Bob needs), Bob can now issue invoices as Alice. It's not
> very useful, since Alice won't honor them, but it is an argument for
> a separate invoice key in future.
>

I believe it is not the intent of rendezvous routing; for the goal "the payee can remain anonymous without being linked to a particular pseudonymous LN node," it occurs to me that Bob knows about Alice and in particular knows that any route going through BobAliceSCID will always go to Alice, which to me defeats the point.

My understanding is simply that Alice will provide a route from some other node, say, Randy the random node, to Alice, as an encrypted onion. Then the payer can simply concatenate the destination onion with the source route to Randy. Alice would use the same public map generated from node gossip to generate the destination-half of the onion from Randy to Alice.

Regards,
ZmnSCPxj