Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-05 📝 Original message: > > But Mallory can do ...

📅 Original date posted:2020-02-05
📝 Original message:
>
> 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).

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.
>

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.

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).

If we're taking into account such KYC pressure, then I believe none of the
solutions we can provide will
be useful. It will be up to the recipient to decide whether he thus wants
to use a normal invoice and
reveal his identity or pass on that payment.

What do you think? Do you believe `option_scid_assign` can do a better job
in such situations?

Cheers,
Bastien

Le mer. 5 févr. 2020 à 02:44, Rusty Russell <rusty at rustcorp.com.au> a
écrit :

> Bastien TEINTURIER <bastien at acinq.fr> writes:
> > Hey again,
> >
> > Otherwise Mallory gets two invoices, and wants to know if they're
> >> actually the same node. Inv1 has nodeid N1, routehint Bob->C1, Inv2 has
> >> nodeid N2, routehint Bob->C2.
> >
> > I think this attack is interesting. AFAICT my proposal defends against
> this
> > because of the way
> > `payment_secret` and `decoy_key` are both used to derive the `decoy_scid`
> > (but don't trust me, do
> > verify that I'm not missing something).
> >
> > If Mallory doesn't use both the right `decoy_node_id` and
> `payment_secret`
> > to compute `P_I`, Bob
> > will not decode that to a valid real `scid` and will return an
> > `unknown_next_peer` which is good
> > for privacy.
>
> But Mallory can do the same attack, I think. Just include the P_I from
> the wrong invoice for Bob.
>
> > It seems to me that
> > https://github.com/lightningnetwork/lightning-rfc/pull/681 cannot defend
> > against this attack. If both invoices are currently valid, Bob will
> forward
> > an HTLC that uses N1
> > with C2 (because Bob has no way of knowing N1 from the onion, for privacy
> > reasons).
> > The only way I'd see to avoid is would be that Alice needs to share her
> > `decoy_node_id`s with
> > Bob (and the mapping to a `decoy_scid`) which means more state to
> > manage...but maybe I'm just
> > missing a better mitigation?
>
> No, Bob can include the scid he used in the update_add_htlc message, so
> Alice can check.
>
> 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.
>
> Thus my preference for a system which doesn't add any requirements on
> the payer.
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200205/08571a4f/attachment.html>;