[Lightning-dev] Decoy node_ids and short_channel_ids

[Bastien TEINTURIER]

Hi Rusty,

Thanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;)

(I think we should probably ban forwarding to private channels,
> too, for similar reasons).


Can you detail why? I believe that forwarding through private channels can
actually be pretty useful in the future for payee privacy (more on that
later).

Note that with any self-assigned SCID schemes, Alice has to respond to
> unknown scids in update_add_htlc with some BADONION code (which makes
> *Bob* give Carol an error response, since Alice can't without revealing
> her identity).


I believe the difference is that in your scheme, Bob would answer with
`unknown_next_peer`. When instead Alice responds with a `BADONION`, the only
thing it reveals is that Alice does use the decoy feature (which Mallory
already knows because she has seen an invoice from Alice). As long as this
behavior is consistent throughout the network, I think both options offer
the
same privacy (unless I'm missing something).

I expect such payments to become
> significant, and as long as paying to a temporary id and paying to a
> private channel looks identical, it's too draconian to ban.


True, that must become the default flow for receiving payments on mobile
wallets.
Granted, my solution would take longer to deploy because it needs to be
added to
sender wallets before receivers can require it.

I've been thinking more about improving my scheme to not require any sender
change, but I don't think that's possible at the moment. As with all
Lightning
tricks though, once we have Schnorr then it's really easy to do.
Alice simply needs to use `s * d_a` as her "preimage" (and the payment point
becomes the P_I Bob needs). That may depend on the exact multi-hop locks
construction we end up using though, so I'm not 100% sure about that yet.

But I did come up with what could be an interesting development.
Nothing prevents the decoy scheme to be used for public channels too, and
for
multiple hops: that enables a cheap form of rendezvous that only costs a few
hundred bytes in the invoice.

Alice would select multiple hops to a rendezvous node, and would apply some
blinding to those hops' `node_id` and `scid`. Alice would include these
decoy
hops in the invoice `routing_hints` (only costs 51 bytes per hop instead of
a
full onion). Mallory would only learn an upper bound on the distance between
Alice and the rendezvous.

I have a detailed version of the scheme in a gist [1] if people want to
take a
deeper look and break it (beer on me to the first one who breaks the
scheme).

[1] https://gist.github.com/t-bast/9972bfe9523bb18395bdedb8dc691faf

Cheers,
Bastien

Le lun. 10 févr. 2020 à 04:40, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
>
> Bastien TEINTURIER <bastien at acinq.fr> writes:
> >> But Mallory can do the same attack, I think.  Just include the P_I from
> >> the wrong invoice for Bob.
> >
> > Good catch, that's true, thanks for keeping me honest there! In that
case
> > my proposal
> > would need the same mitigation as yours, Bob will need to include the
> > `scid` he received
> > in `update_add_htlc` (this is in fact not that hard once we allow TLV
> > extensions on every
> > message).
>
> Yes, I've added this to the PR.  Which gives a new validation path, I
> think:
>
> ## Figuring out what nodeid to use to decode onion
>
> 1. Look up scid from HTLC; if it didn't include one, use default.
> 2. Look up payment_hash; if no invoice is found, use default.
> 3. If invoice specified this scid, get nodeid and use that.
> 4. ... and refuse to forward the HTLC (it must terminate here).
>
> My plan is to add an argument to `invoice` which is an array of one or
> more scids: we get a temporary scids for each peer and use them in the
> routehints.  We also assign a random temporary nodeid to that invoice.
>
> The above algo is designed to ensure we behave like any other node which
> has no idea about this nodeid if Mallory:
>
> 1. tries to use a temporary node id on a normal channel to us.
> 2. tries to pay another invoice using this temporary node id.
> 3. tries to probe our outgoing channels using this routing hint
>    (I think we should probably ban forwarding to private channels,
>    too, for similar reasons).
>
> ---
>
> Note that with any self-assigned SCID schemes, Alice has to respond to
> unknown scids in update_add_htlc with some BADONION code (which makes
> *Bob* give Carol an error response, since Alice can't without revealing
> her identity).
>
> With Bob-assigned SCIDs, Alice simply needs to make him unallocate
> it before forgetting the invoice, so she will simply never see old
> invoices.
>
> (All these schemes give limited privacy, of course: Bob knows who Alice
> is, and fingerprinting and liveness attacks are always possible).
>
> > I'm extremely nervous about custodial lightning services restricting
> >> what they will pay to.  This is not theoretical: they will come under
> >> immense KYC pressure in the near future, which means they cannot pay
> >> arbitrary invoices.
> 1>>
> >
> > That's a very good point, thanks for raising this. However I believe
that
> > there are (and will be) enough
> > non-custodial wallets to let motivated users pay whatever they want.
Users
> > can even run their own
> > node to pay such invoices if needed.
>
> Not if ln_strike (no, the other one!) is the future.
>
> > If you are using a custodial wallet and KYC pressure kicks in, then
> > regardless of that feature law may
> > require users to completely reveal who they are paying, so even normal
> > payments wouldn't protect
> > them, don't you think? Regulation could for example disallow paying via
> > unannounced channels entirely
> > (or require you to show the funding tx associated to your unannounced
> > channel).
>
> Actually, as long as the same method is required for both normal private
> channels (which will all use non-tx-based short_channel_ids in the near
> future I hope!), I don't really mind.  I expect such payments to become
> significant, and as long as paying to a temporary id and paying to a
> private channel looks identical, it's too draconian to ban.  A business
> would probably meet any KYC requirements by simply asking the user
> (perhaps over a certain amount, etc).
>
> (I've put my implementation on hold for a moment while I'm supposed to
> be releasing 0.8.1-rc1 RSN!)
>
> Cheers,
> Rusty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200211/41e5aa47/attachment.html>