{"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-11\n📝 Original message:\nHi Rusty,\n\nThanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;)\n\n(I think we should probably ban forwarding to private channels,\n\u003e too, for similar reasons).\n\n\nCan you detail why? I believe that forwarding through private channels can\nactually be pretty useful in the future for payee privacy (more on that\nlater).\n\nNote that with any self-assigned SCID schemes, Alice has to respond to\n\u003e unknown scids in update_add_htlc with some BADONION code (which makes\n\u003e *Bob* give Carol an error response, since Alice can't without revealing\n\u003e her identity).\n\n\nI believe the difference is that in your scheme, Bob would answer with\n`unknown_next_peer`. When instead Alice responds with a `BADONION`, the only\nthing it reveals is that Alice does use the decoy feature (which Mallory\nalready knows because she has seen an invoice from Alice). As long as this\nbehavior is consistent throughout the network, I think both options offer\nthe\nsame privacy (unless I'm missing something).\n\nI expect such payments to become\n\u003e significant, and as long as paying to a temporary id and paying to a\n\u003e private channel looks identical, it's too draconian to ban.\n\n\nTrue, that must become the default flow for receiving payments on mobile\nwallets.\nGranted, my solution would take longer to deploy because it needs to be\nadded to\nsender wallets before receivers can require it.\n\nI've been thinking more about improving my scheme to not require any sender\nchange, but I don't think that's possible at the moment. As with all\nLightning\ntricks though, once we have Schnorr then it's really easy to do.\nAlice simply needs to use `s * d_a` as her \"preimage\" (and the payment point\nbecomes the P_I Bob needs). That may depend on the exact multi-hop locks\nconstruction we end up using though, so I'm not 100% sure about that yet.\n\nBut I did come up with what could be an interesting development.\nNothing prevents the decoy scheme to be used for public channels too, and\nfor\nmultiple hops: that enables a cheap form of rendezvous that only costs a few\nhundred bytes in the invoice.\n\nAlice would select multiple hops to a rendezvous node, and would apply some\nblinding to those hops' `node_id` and `scid`. Alice would include these\ndecoy\nhops in the invoice `routing_hints` (only costs 51 bytes per hop instead of\na\nfull onion). Mallory would only learn an upper bound on the distance between\nAlice and the rendezvous.\n\nI have a detailed version of the scheme in a gist [1] if people want to\ntake a\ndeeper look and break it (beer on me to the first one who breaks the\nscheme).\n\n[1] https://gist.github.com/t-bast/9972bfe9523bb18395bdedb8dc691faf\n\nCheers,\nBastien\n\nLe lun. 10 févr. 2020 à 04:40, Rusty Russell \u003crusty at rustcorp.com.au\u003e a\nécrit :\n\u003e\n\u003e Bastien TEINTURIER \u003cbastien at acinq.fr\u003e writes:\n\u003e \u003e\u003e But Mallory can do the same attack, I think.  Just include the P_I from\n\u003e \u003e\u003e the wrong invoice for Bob.\n\u003e \u003e\n\u003e \u003e Good catch, that's true, thanks for keeping me honest there! In that\ncase\n\u003e \u003e my proposal\n\u003e \u003e would need the same mitigation as yours, Bob will need to include the\n\u003e \u003e `scid` he received\n\u003e \u003e in `update_add_htlc` (this is in fact not that hard once we allow TLV\n\u003e \u003e extensions on every\n\u003e \u003e message).\n\u003e\n\u003e Yes, I've added this to the PR.  Which gives a new validation path, I\n\u003e think:\n\u003e\n\u003e ## Figuring out what nodeid to use to decode onion\n\u003e\n\u003e 1. Look up scid from HTLC; if it didn't include one, use default.\n\u003e 2. Look up payment_hash; if no invoice is found, use default.\n\u003e 3. If invoice specified this scid, get nodeid and use that.\n\u003e 4. ... and refuse to forward the HTLC (it must terminate here).\n\u003e\n\u003e My plan is to add an argument to `invoice` which is an array of one or\n\u003e more scids: we get a temporary scids for each peer and use them in the\n\u003e routehints.  We also assign a random temporary nodeid to that invoice.\n\u003e\n\u003e The above algo is designed to ensure we behave like any other node which\n\u003e has no idea about this nodeid if Mallory:\n\u003e\n\u003e 1. tries to use a temporary node id on a normal channel to us.\n\u003e 2. tries to pay another invoice using this temporary node id.\n\u003e 3. tries to probe our outgoing channels using this routing hint\n\u003e    (I think we should probably ban forwarding to private channels,\n\u003e    too, for similar reasons).\n\u003e\n\u003e ---\n\u003e\n\u003e Note that with any self-assigned SCID schemes, Alice has to respond to\n\u003e unknown scids in update_add_htlc with some BADONION code (which makes\n\u003e *Bob* give Carol an error response, since Alice can't without revealing\n\u003e her identity).\n\u003e\n\u003e With Bob-assigned SCIDs, Alice simply needs to make him unallocate\n\u003e it before forgetting the invoice, so she will simply never see old\n\u003e invoices.\n\u003e\n\u003e (All these schemes give limited privacy, of course: Bob knows who Alice\n\u003e is, and fingerprinting and liveness attacks are always possible).\n\u003e\n\u003e \u003e I'm extremely nervous about custodial lightning services restricting\n\u003e \u003e\u003e what they will pay to.  This is not theoretical: they will come under\n\u003e \u003e\u003e immense KYC pressure in the near future, which means they cannot pay\n\u003e \u003e\u003e arbitrary invoices.\n\u003e 1\u003e\u003e\n\u003e \u003e\n\u003e \u003e That's a very good point, thanks for raising this. However I believe\nthat\n\u003e \u003e there are (and will be) enough\n\u003e \u003e non-custodial wallets to let motivated users pay whatever they want.\nUsers\n\u003e \u003e can even run their own\n\u003e \u003e node to pay such invoices if needed.\n\u003e\n\u003e Not if ln_strike (no, the other one!) is the future.\n\u003e\n\u003e \u003e If you are using a custodial wallet and KYC pressure kicks in, then\n\u003e \u003e regardless of that feature law may\n\u003e \u003e require users to completely reveal who they are paying, so even normal\n\u003e \u003e payments wouldn't protect\n\u003e \u003e them, don't you think? Regulation could for example disallow paying via\n\u003e \u003e unannounced channels entirely\n\u003e \u003e (or require you to show the funding tx associated to your unannounced\n\u003e \u003e channel).\n\u003e\n\u003e Actually, as long as the same method is required for both normal private\n\u003e channels (which will all use non-tx-based short_channel_ids in the near\n\u003e future I hope!), I don't really mind.  I expect such payments to become\n\u003e significant, and as long as paying to a temporary id and paying to a\n\u003e private channel looks identical, it's too draconian to ban.  A business\n\u003e would probably meet any KYC requirements by simply asking the user\n\u003e (perhaps over a certain amount, etc).\n\u003e\n\u003e (I've put my implementation on hold for a moment while I'm supposed to\n\u003e be releasing 0.8.1-rc1 RSN!)\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200211/41e5aa47/attachment.html\u003e"}