{"type":"rich","version":"1.0","title":"Rusty Russell [ARCHIVE] wrote","author_name":"Rusty Russell [ARCHIVE] (npub1zw…hkhpx)","author_url":"https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-03-09\n📝 Original message:\nI recently hit a dead-end on rendezvous routing; the single-use\nrequirement is a showstopper for offers (which are supposed to be static\nand reusable).\n\nFortunately, t-bast has a scheme for blinded paths (see\nhttps://gist.github.com/t-bast/9972bfe9523bb18395bdedb8dc691faf ) so\nI've been examining that more closely.  I think it can be simplified\nto use more standard primitives.\n\nThe problem: Alice wants to present Mallory with a path (Carol, Bob,\nAlice) for which he can create an onion, which is obscured in some way,\nbut can be unobscured by the various nodes.  Mallory should be forced to\nuse the entire path.\n\nAlice can give Mallory two ECDH blobs to place inside the per-hop\npayload to establish shared secrets with Bob and Carol.  But crucially,\nBob needs the secret *before* he can unwrap the onion, so the ECDH\nblob for the next peer needs to be sent alongside the onion itself.\n\nt-bast proposed using the secret to XOR the scid, but Christian\nsuggested it's more powerful to encrypt a general payload.\n\nWhat does this leave us with?\n\n1. A new invoice letter `b`.  Encodes\n   1 or more pubkey/feebase/feeprop/cltvdelta/features/encblob.\n\n2. An additional (tlv of course) field to update_add_htlc, `blinding`.\n\n3. New `tlv_payload` field `encblob` (varlen).\n\n4. ECDH on incoming `blinding` to get a shared secret which tells\n   this node how to tweak its nodeid to decrypt onion, and also how to\n   decrypt `encblob`.  This gives a tlv, which presumably contains\n   `short_channel_id` as well as `blinding`.\n\n5. Use `blinding` for the next update_add_htlc.\n\n6. If you get an error from downstream and you sent `blinding`, turn it\n   into your own error for maximum obfuscation.  Perhaps a new\n   \"blinded_path_error\"?  Obviously does not include a channel_update :)\n\nSo, if you get an invoice `b`, with path starting at (known) Carol:\n\n        Carol/1/1/9/\"\"/enc1\n          Bob'/1/1/9/\"\"/enc2\n            [Optional: decoy hops...]\n\nPayer constructs the onion to get to Carol as normal, then:\n\n        Carol: No `blinding` in incoming HTLC, but once it decrypts the\n               onion, she sees `encblob` (value enc1).  Uses first 32\n               bytes of `enc1` as `blinding`: do ECDH to get SS1, uses\n               SS1 to decrypt rest to get next scid and `blinding`, send\n               `blinding` with update_add_htlc to Bob.\n\n        Bob: Gets `blinding` from update_add_htlc. ECDH -\u003e SS2.  Tweak\n               own key with SS2 to decode onion.  Use SS2 to decrypt\n               `enc2` to get next scid and blinding.  Send `blinding`\n               with update_add_htlc to Alice.\n\n        Alice: Gets `blinding` from update_add_htlc. ECDH -\u003e SS3.  Tweak\n               own key with SS3 to decode onion.  If it put in decoy\n               hops, this onion won't be terminal, but otherwise it can\n               be treated as terminal iff `blinding` is the expected value\n               for this invoice.\n\nNote that this means no payment secret is necessary, since the incoming\n`blinding` serves the same purpose.  If we wanted to, we could (ab)use\npayment_secret as the first 32-bytes to put in Carol's enc1 (i.e. it's\nthe ECDH for Carol to decrypt enc1).\n\nThoughts?\nRusty."}