rich1.0npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0shttps://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0snjumphttps://nostr.ae📅 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>