{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-02-24\n📝 Original message:\nGood morning list,\n\nAfter exploring decoys [1], which is a cheap way of doing route blinding,\nI'm turning back to exploring rendezvous.\nThe previous mails on the mailing list mentioned that there was a\ntechnicality\nto make the HMACs check out, but didn't provide a lot of details.\nThe issue is that the filler generation needs to take into account some hops\nthat will be added *later*, by the payer.\n\nHowever it is quite easy to work-around, with a few space trade-offs.\nLet's consider a typical rendezvous setup, where Alice wants to be paid via\nrendezvous Bob, and Carol wants to pay that invoice:\n\nCarol -\u003e ... -\u003e Bob -\u003e ... -\u003e Alice\n\nIf Alice knows how many bytes Carol is going to use for her part of the\nonion\npayloads, Alice can easily take them into account when generating her\nfiller by\npre-pending the same amount of `0` bytes. It seems reasonable to impose a\nfixed\nnumber of onion bytes for each side of the rendezvous (650 each?) so Alice\nwould\nknow that amount.\n\nWhen Carol completes the onion with her part of the route, she simply needs\nto\ngenerate filler data for her part of the route following the normal Sphinx\nprotocol\nand apply it to the onion she found in the invoice.\n\nBut the tricky part is that she needs to give Bob a way of generating the\nsame\nfiller data to unapply it. Then all HMACs correctly check out.\n\nI see two ways of doing that:\n\n* Carol simply sends that filler (650 bytes), probably via a TLV in\n`update_add_htlc`.\nThis means every intermediate hop needs to forward that, which is painful\nand\npotentially leaking too much data.\n* Carol provides Bob with the rho keys used to generate her filler, and the\nlength\nused by each hop. This leaks to Bob an upper bound on the number of hops\nand the\nnumber of bytes sent to each hop.\n\nSince shift-and-xor kind of crypto is hard to read as equations, but very\neasy to\nread as diagrams, I spent a bit of time doing beautiful ASCII art [2].\nDon't hesitate\nto have a look at it to find more details about how that works. You can\nalso print\nthat on t-shirts to look fancy at conferences. I also have some sample code\nworking\nin eclair [3] for those who can read Scala without getting headaches.\n\nAre there other tricks we can use to reconcile both sides of the onion at\nBob's?\nMaybe cdecker (or someone else) has an ace up his sleeve for me there? :)\n\nOne important thing to note is that rendezvous on normal onions will be\ncostly to\nintegrate into invoices: it takes 1366 bytes to include one onion, and if\nwe want\nto handle route failures or let the sender use multi-part, we will need to\nhave a\nhandful of pre-encrypted onions in the invoice (hence a few kB, which may\nnot be\npractical for QR codes).\n\nBut I did mention before that doing rendezvous on the trampoline onion\ncould have\nbetter properties [4]. When doing that, having Carol transmit her filler\ndata only\nto Bob, via the outer onion payload becomes practical and doesn't leak\ninformation.\nMulti-part would work with a single trampoline onion in the invoice (~500\nbytes),\nbecause nodes can do MPP between trampoline nodes thanks to the\nonion-in-onion\nconstruction. We simply need to decide the size of the trampoline onion to\nallow\neach side of the rendezvous to be able to insert a number of hops we're\ncomfortable\nwith. You can find more details in the \"Rendezvous on a trampoline\" section\nof [2].\n\nI'm really interested in other approaches to making rendezvous work with\nthe HMACs\ncorrectly checking out. If people on this list have drafts, intuitions or\nrandom\nthoughts about possible constructions, please share them, I'd be happy to\ndive into\nthem to explore alternatives to the one I found, hoping we can make this\nwork and\nprovide this feature to our users in the near future.\n\nA small side-note on Hornet. Hornet does offer many features that I believe\nwe will\nwant in Lightning in the future. It may seem that doing a custom rendezvous\nscheme\nis a waste of time since we'll ditch it once/if we implement Hornet. While\nthat is\ntrue in the long run, I believe that if we're able to find a rendezvous\nscheme that\nisn't too much work to implement, it makes sense to have something\navailable soon-ish.\nHornet will likely be a longer-term effort that we won't get as soon as\nwe'd like\n(especially since it will probably require a network-wide update). But who\nknows, maybe\nwe may see that we are trying to create many features that are already\nbuilt into Hornet\n(rendezvous, directed message support, etc) and will decide to implement\nHornet sooner\nthan expected?\n\nCheers,\nBastien\n\n[1]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002435.html\n[2] https://gist.github.com/t-bast/ab42a7f52eb2e73105557957c8359601\n[3] https://github.com/ACINQ/eclair/tree/sphinx-rendezvous\n[4]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002237.html\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200224/02d2cd82/attachment-0001.html\u003e"}