📅 Original date posted:2018-11-04
📝 Original message:
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.
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:52:08
in reply to nevent1q…xy0c
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:52:08Event JSON
{
"id": "7ab5570379b824ac9686162dcfc87d3af2aafdcad45085ce5c3a6de416f852f8",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315128,
"kind": 1,
"tags": [
[
"e",
"592517461d2388cb6daa0eaf59e03e4207dbca848edb9b0b5038bad8ed99bd4e",
"",
"root"
],
[
"e",
"a3db43dcb11406e8047d1a9282ca04eaf6a6ea4f9ba0c7ac39c12b093b0bdc73",
"",
"reply"
],
[
"p",
"880fa8c3080c3bd98e574cfcd6d6f53fd13e0516c40ea3f46295438b0c07bdf5"
]
],
"content": "📅 Original date posted:2018-11-04\n📝 Original message:\nCJP \u003ccjp at ultimatestunts.nl\u003e writes:\n\u003e\u003e Looking through BOLT 4, the text assumes inherently that source\n\u003e\u003e routing is done, and even has a shared secret between hop and\n\u003e\u003e source. However, it may be possible in rendezvous routing to simply\n\u003e\u003e provide the blinding key (while hiding everything beyond the first\n\u003e\u003e hop on the destination half of the route).\n\u003e\n\u003e Sounds like it makes sense; I need to look into it.\n\nHere's my attempt to design a \"merchant forward\" service using stuff we\nhave today.\n\nAlice wants to remain anonymous, even from the lightning network. Bob's\nnode offers a forwarding service. Alice pays Bob (base + percentage?),\ngives a path Bob-\u003eAlice, and Bob gives Alice a short-channel-id\n(BobAliceSCID) and privkey to use (BobAliceSecretKey). Anything sent\nfrom Bob to this short channel id and pubkey is in fact forwarded via a\nnew HTLC to Alice.\n\nAlice identity BobAliceKey to create an invoice, with a route-hint to\nsay pubkey=Bob, short_channel_id=BobAliceSCID. Alice can sign\nthat invoice, and Bob can decode the incoming payment, from which it\ncreates a new HTLC to pay Alice. The payer doesn't even know this\narrangement exists: it looks exactly like Alice has a private channel\nwith Bob.\n\nThe minor downside: because we conflate invoice keys (Alice needs) and\nonion keys (Bob needs), Bob can now issue invoices as Alice. It's not\nvery useful, since Alice won't honor them, but it is an argument for\na separate invoice key in future.\n\nCheers,\nRusty.",
"sig": "4609c702da466ae46ef1d1e1c6beb459183661ff7a53278e733163ade153777b0b5a4c5377c510dde2e0c14c7d9c5ccfa65f2c12693c8617a7ace69dbc3e6805"
}