Good morning CJP, On Monday, November 5, 2018 4:04 PM, CJP <c...@ultimatestunts.nl> wrote:
> Rusty, > > In your proposal, I guess it is more or less widely known that Bob is > providing this forwarding service. Wouldn't Bob risk being excluded > from the side of the network with the more harsh regulatory conditions, > based on this knowledge? Bob might actually face even worse penalties > for providing such a service. > > The nice thing about rendez-vous routing is that any forwarding node > can be a rendez-vous point, and even the node itself wouldn't know > about it. The case where a payment is routed from and to the same > channel could be a hint though: normally that makes no sense, but if > payer and payee make their part of the route independently, the > combined route can often end up like that. TODO: check if forwarding > nodes are currently cool with such weird forwarding requests. This is allowed within the protocol and to my knowledge existing node software do not particularly care. However, it is indeed a concern as it allows somebody to notice such use of rendezvous routing. A use of this (forwarding to the same channel as receiving) is to give donations to a node without actually requiring an invoice to that node. You simply route a circle to yourself to an invoice you generated yourself, and hide the donation to some node as fees paid for forwarding through that node. Nodes will accept as fee any amount higher than the feerate they indicate in gossip. Regards, ZmnSCPxj > > CJP > > Rusty Russell schreef op ma 05-11-2018 om 10:56 [+1030]: > > > CJP c...@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. > > Cheers, > > Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
