<div dir="ltr">Hi Rusty,<br><br>Thanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;)<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(I think we should probably ban forwarding to private channels,<br>too, for similar reasons).</blockquote><br>Can you detail why? I believe that forwarding through private channels can<br>actually be pretty useful in the future for payee privacy (more on that later).<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Note that with any self-assigned SCID schemes, Alice has to respond to<br>unknown scids in update_add_htlc with some BADONION code (which makes<br>*Bob* give Carol an error response, since Alice can't without revealing<br>her identity).</blockquote><br>I believe the difference is that in your scheme, Bob would answer with<br>`unknown_next_peer`. When instead Alice responds with a `BADONION`, the only<br>thing it reveals is that Alice does use the decoy feature (which Mallory<br>already knows because she has seen an invoice from Alice). As long as this<br>behavior is consistent throughout the network, I think both options offer the<br>same privacy (unless I'm missing something).<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I expect such payments to become<br>significant, and as long as paying to a temporary id and paying to a<br>private channel looks identical, it's too draconian to ban.</blockquote><br>True, that must become the default flow for receiving payments on mobile wallets.<br>Granted, my solution would take longer to deploy because it needs to be added to<br>sender wallets before receivers can require it.<br><br>I've been thinking more about improving my scheme to not require any sender<br>change, but I don't think that's possible at the moment. As with all Lightning<br>tricks though, once we have Schnorr then it's really easy to do.<br>Alice simply needs to use `s * d_a` as her "preimage" (and the payment point<br>becomes the P_I Bob needs). That may depend on the exact multi-hop locks<br>construction we end up using though, so I'm not 100% sure about that yet.<br><br>But I did come up with what could be an interesting development.<br>Nothing prevents the decoy scheme to be used for public channels too, and for<br>multiple hops: that enables a cheap form of rendezvous that only costs a few<br>hundred bytes in the invoice.<br><br>Alice would select multiple hops to a rendezvous node, and would apply some<br>blinding to those hops' `node_id` and `scid`. Alice would include these decoy<br>hops in the invoice `routing_hints` (only costs 51 bytes per hop instead of a<br>full onion). Mallory would only learn an upper bound on the distance between<br>Alice and the rendezvous.<br><br>I have a detailed version of the scheme in a gist [1] if people want to take a<br>deeper look and break it (beer on me to the first one who breaks the scheme).<br><br>[1] <a href="https://gist.github.com/t-bast/9972bfe9523bb18395bdedb8dc691faf">https://gist.github.com/t-bast/9972bfe9523bb18395bdedb8dc691faf</a><div><br></div><div>Cheers,</div><div>Bastien</div><div><br>Le lun. 10 févr. 2020 à 04:40, Rusty Russell <<a href="mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>> a écrit :<br>><br>> Bastien TEINTURIER <<a href="mailto:bastien@acinq.fr">bastien@acinq.fr</a>> writes:<br>> >> But Mallory can do the same attack, I think.  Just include the P_I from<br>> >> the wrong invoice for Bob.<br>> ><br>> > Good catch, that's true, thanks for keeping me honest there! In that case<br>> > my proposal<br>> > would need the same mitigation as yours, Bob will need to include the<br>> > `scid` he received<br>> > in `update_add_htlc` (this is in fact not that hard once we allow TLV<br>> > extensions on every<br>> > message).<br>><br>> Yes, I've added this to the PR.  Which gives a new validation path, I<br>> think:<br>><br>> ## Figuring out what nodeid to use to decode onion<br>><br>> 1. Look up scid from HTLC; if it didn't include one, use default.<br>> 2. Look up payment_hash; if no invoice is found, use default.<br>> 3. If invoice specified this scid, get nodeid and use that.<br>> 4. ... and refuse to forward the HTLC (it must terminate here).<br>><br>> My plan is to add an argument to `invoice` which is an array of one or<br>> more scids: we get a temporary scids for each peer and use them in the<br>> routehints.  We also assign a random temporary nodeid to that invoice.<br>><br>> The above algo is designed to ensure we behave like any other node which<br>> has no idea about this nodeid if Mallory:<br>><br>> 1. tries to use a temporary node id on a normal channel to us.<br>> 2. tries to pay another invoice using this temporary node id.<br>> 3. tries to probe our outgoing channels using this routing hint<br>>    (I think we should probably ban forwarding to private channels,<br>>    too, for similar reasons).<br>><br>> ---<br>><br>> Note that with any self-assigned SCID schemes, Alice has to respond to<br>> unknown scids in update_add_htlc with some BADONION code (which makes<br>> *Bob* give Carol an error response, since Alice can't without revealing<br>> her identity).<br>><br>> With Bob-assigned SCIDs, Alice simply needs to make him unallocate<br>> it before forgetting the invoice, so she will simply never see old<br>> invoices.<br>><br>> (All these schemes give limited privacy, of course: Bob knows who Alice<br>> is, and fingerprinting and liveness attacks are always possible).<br>><br>> > I'm extremely nervous about custodial lightning services restricting<br>> >> what they will pay to.  This is not theoretical: they will come under<br>> >> immense KYC pressure in the near future, which means they cannot pay<br>> >> arbitrary invoices.<br>> 1>><br>> ><br>> > That's a very good point, thanks for raising this. However I believe that<br>> > there are (and will be) enough<br>> > non-custodial wallets to let motivated users pay whatever they want. Users<br>> > can even run their own<br>> > node to pay such invoices if needed.<br>><br>> Not if ln_strike (no, the other one!) is the future.<br>><br>> > If you are using a custodial wallet and KYC pressure kicks in, then<br>> > regardless of that feature law may<br>> > require users to completely reveal who they are paying, so even normal<br>> > payments wouldn't protect<br>> > them, don't you think? Regulation could for example disallow paying via<br>> > unannounced channels entirely<br>> > (or require you to show the funding tx associated to your unannounced<br>> > channel).<br>><br>> Actually, as long as the same method is required for both normal private<br>> channels (which will all use non-tx-based short_channel_ids in the near<br>> future I hope!), I don't really mind.  I expect such payments to become<br>> significant, and as long as paying to a temporary id and paying to a<br>> private channel looks identical, it's too draconian to ban.  A business<br>> would probably meet any KYC requirements by simply asking the user<br>> (perhaps over a certain amount, etc).<br>><br>> (I've put my implementation on hold for a moment while I'm supposed to<br>> be releasing 0.8.1-rc1 RSN!)<br>><br>> Cheers,<br>> Rusty.</div></div>