{"type":"rich","version":"1.0","author_name":"npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","author_url":"https://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-02-24\n📝 Original message:\nHi Bastien,\n\nseems you were a bit quicker than I was with my writeup of my\nproposal. I came up with a scheme that allows us to drop a large part of\nthe partial onion, so that it can indeed fit into an outer onion, and\nthe rendez-vous node RV can re-construct the original packet from the\nincluded data [1].\n\nThe construction comes down to initializing the part of the routing info\nstring that is not going to be used, in such a way that the incremental\nunwrappings at the nodes in the partial onion cancels out. Like you\nmentioned in your mail it comes down extending the filler generation to\nalso cover the unused part and then applying all the encryption streams\nxored to the unused space. By doing this we get the middle part of the\nonion consisting of only 0x00 bytes.\n\nI then decided to apply an additional ChaCha20 stream to this prefill,\nsuch that the onion will not consist of mostly 0x00 bytes which would be\na dead giveaway to `RV+1` that `RV` was a rendez-vous node.\n\nThe process for the partial onion creator boils down to:\n\n - Compute a path from `RV` of its choice to recipient `R`.\n - Compute a shared secret using a random ephemeral private key and\n  `RV`s public key, and then generate a prefill-key\n - Compute the prefill by combining the correct substrings of the\n   encryption streams for the nodes along the path, then add the\n   ChaCha20 stream keyed with the prefill-key.\n - Wrap the onion, including payloads for each of the nodes along path\n   `RV` to `R`\n - Trim out the unused space, which now will match the obfuscation\n   stream generated with the prefill-key\n\nAs an example such an onion, with 5 legacy hops (65 byte each) results\nin a 325 + 66 bytes onion, and we save 975 bytes. See [2] for an example\nof how this looks like.\n\nThe sender `S` then just does the following:\n\n - Compute a route from `S` to `RV`\n - Build an onion with the route, specifying the trimmed partial onion\n   as payload, along with the usual parameters, for `RV`\n - Initiate payment with the constructed onion\n\nUpon receiving an incoming HTLC with a partial onion the rendez-vous\nnode `RV` then just does the following:\n\n - Verify all parameters as usual\n - Extract the partial onion\n - Use the ephemeral key from the partial onion to generate the shared\n   secret and the prefill key\n - Generate the prefill stream and insert it in the correct place,\n   before the HMAC. This reconstitutes the original routing packet\n - Swap out the original onion with the reconstituted onion and forward.\n\nMy writeup [1] is an early draft, but I wanted to get it out early to\ngive the discussion a basis to work off. I'll revisit it a couple of\ntimes before opening a PR, but feel free to shout at me if I have\nforgotten to consider something :-)\n\nCheers,\nChristian\n\n[1] https://github.com/lightningnetwork/lightning-rfc/blob/rendez-vous/proposals/0001-rendez-vous.md\n[2] https://gist.github.com/cdecker/ec06452bc470749d9f6d2de73651c5fd\n\nBastien TEINTURIER via Lightning-dev\n\u003clightning-dev at lists.linuxfoundation.org\u003e writes:\n\u003e Good morning list,\n\u003e\n\u003e After exploring decoys [1], which is a cheap way of doing route blinding,\n\u003e I'm turning back to exploring rendezvous.\n\u003e The previous mails on the mailing list mentioned that there was a\n\u003e technicality\n\u003e to make the HMACs check out, but didn't provide a lot of details.\n\u003e The issue is that the filler generation needs to take into account some hops\n\u003e that will be added *later*, by the payer.\n\u003e\n\u003e However it is quite easy to work-around, with a few space trade-offs.\n\u003e Let's consider a typical rendezvous setup, where Alice wants to be paid via\n\u003e rendezvous Bob, and Carol wants to pay that invoice:\n\u003e\n\u003e Carol -\u003e ... -\u003e Bob -\u003e ... -\u003e Alice\n\u003e\n\u003e If Alice knows how many bytes Carol is going to use for her part of the\n\u003e onion\n\u003e payloads, Alice can easily take them into account when generating her\n\u003e filler by\n\u003e pre-pending the same amount of `0` bytes. It seems reasonable to impose a\n\u003e fixed\n\u003e number of onion bytes for each side of the rendezvous (650 each?) so Alice\n\u003e would\n\u003e know that amount.\n\u003e\n\u003e When Carol completes the onion with her part of the route, she simply needs\n\u003e to\n\u003e generate filler data for her part of the route following the normal Sphinx\n\u003e protocol\n\u003e and apply it to the onion she found in the invoice.\n\u003e\n\u003e But the tricky part is that she needs to give Bob a way of generating the\n\u003e same\n\u003e filler data to unapply it. Then all HMACs correctly check out.\n\u003e\n\u003e I see two ways of doing that:\n\u003e\n\u003e * Carol simply sends that filler (650 bytes), probably via a TLV in\n\u003e `update_add_htlc`.\n\u003e This means every intermediate hop needs to forward that, which is painful\n\u003e and\n\u003e potentially leaking too much data.\n\u003e * Carol provides Bob with the rho keys used to generate her filler, and the\n\u003e length\n\u003e used by each hop. This leaks to Bob an upper bound on the number of hops\n\u003e and the\n\u003e number of bytes sent to each hop.\n\u003e\n\u003e Since shift-and-xor kind of crypto is hard to read as equations, but very\n\u003e easy to\n\u003e read as diagrams, I spent a bit of time doing beautiful ASCII art [2].\n\u003e Don't hesitate\n\u003e to have a look at it to find more details about how that works. You can\n\u003e also print\n\u003e that on t-shirts to look fancy at conferences. I also have some sample code\n\u003e working\n\u003e in eclair [3] for those who can read Scala without getting headaches.\n\u003e\n\u003e Are there other tricks we can use to reconcile both sides of the onion at\n\u003e Bob's?\n\u003e Maybe cdecker (or someone else) has an ace up his sleeve for me there? :)\n\u003e\n\u003e One important thing to note is that rendezvous on normal onions will be\n\u003e costly to\n\u003e integrate into invoices: it takes 1366 bytes to include one onion, and if\n\u003e we want\n\u003e to handle route failures or let the sender use multi-part, we will need to\n\u003e have a\n\u003e handful of pre-encrypted onions in the invoice (hence a few kB, which may\n\u003e not be\n\u003e practical for QR codes).\n\u003e\n\u003e But I did mention before that doing rendezvous on the trampoline onion\n\u003e could have\n\u003e better properties [4]. When doing that, having Carol transmit her filler\n\u003e data only\n\u003e to Bob, via the outer onion payload becomes practical and doesn't leak\n\u003e information.\n\u003e Multi-part would work with a single trampoline onion in the invoice (~500\n\u003e bytes),\n\u003e because nodes can do MPP between trampoline nodes thanks to the\n\u003e onion-in-onion\n\u003e construction. We simply need to decide the size of the trampoline onion to\n\u003e allow\n\u003e each side of the rendezvous to be able to insert a number of hops we're\n\u003e comfortable\n\u003e with. You can find more details in the \"Rendezvous on a trampoline\" section\n\u003e of [2].\n\u003e\n\u003e I'm really interested in other approaches to making rendezvous work with\n\u003e the HMACs\n\u003e correctly checking out. If people on this list have drafts, intuitions or\n\u003e random\n\u003e thoughts about possible constructions, please share them, I'd be happy to\n\u003e dive into\n\u003e them to explore alternatives to the one I found, hoping we can make this\n\u003e work and\n\u003e provide this feature to our users in the near future.\n\u003e\n\u003e A small side-note on Hornet. Hornet does offer many features that I believe\n\u003e we will\n\u003e want in Lightning in the future. It may seem that doing a custom rendezvous\n\u003e scheme\n\u003e is a waste of time since we'll ditch it once/if we implement Hornet. While\n\u003e that is\n\u003e true in the long run, I believe that if we're able to find a rendezvous\n\u003e scheme that\n\u003e isn't too much work to implement, it makes sense to have something\n\u003e available soon-ish.\n\u003e Hornet will likely be a longer-term effort that we won't get as soon as\n\u003e we'd like\n\u003e (especially since it will probably require a network-wide update). But who\n\u003e knows, maybe\n\u003e we may see that we are trying to create many features that are already\n\u003e built into Hornet\n\u003e (rendezvous, directed message support, etc) and will decide to implement\n\u003e Hornet sooner\n\u003e than expected?\n\u003e\n\u003e Cheers,\n\u003e Bastien\n\u003e\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002435.html\n\u003e [2] https://gist.github.com/t-bast/ab42a7f52eb2e73105557957c8359601\n\u003e [3] https://github.com/ACINQ/eclair/tree/sphinx-rendezvous\n\u003e [4]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002237.html\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"}