{"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-05\n📝 Original message:\n\u003e\n\u003e But Mallory can do the same attack, I think.  Just include the P_I from\n\u003e the wrong invoice for Bob.\n\u003e\n\nGood catch, that's true, thanks for keeping me honest there! In that case\nmy proposal\nwould need the same mitigation as yours, Bob will need to include the\n`scid` he received\nin `update_add_htlc` (this is in fact not that hard once we allow TLV\nextensions on every\nmessage).\n\nI'm extremely nervous about custodial lightning services restricting\n\u003e what they will pay to.  This is not theoretical: they will come under\n\u003e immense KYC pressure in the near future, which means they cannot pay\n\u003e arbitrary invoices.\n\u003e\n\nThat's a very good point, thanks for raising this. However I believe that\nthere are (and will be) enough\nnon-custodial wallets to let motivated users pay whatever they want. Users\ncan even run their own\nnode to pay such invoices if needed.\n\nIf you are using a custodial wallet and KYC pressure kicks in, then\nregardless of that feature law may\nrequire users to completely reveal who they are paying, so even normal\npayments wouldn't protect\nthem, don't you think? Regulation could for example disallow paying via\nunannounced channels entirely\n(or require you to show the funding tx associated to your unannounced\nchannel).\n\nIf we're taking into account such KYC pressure, then I believe none of the\nsolutions we can provide will\nbe useful. It will be up to the recipient to decide whether he thus wants\nto use a normal invoice and\nreveal his identity or pass on that payment.\n\nWhat do you think? Do you believe `option_scid_assign` can do a better job\nin such situations?\n\nCheers,\nBastien\n\nLe mer. 5 févr. 2020 à 02:44, Rusty Russell \u003crusty at rustcorp.com.au\u003e a\nécrit :\n\n\u003e Bastien TEINTURIER \u003cbastien at acinq.fr\u003e writes:\n\u003e \u003e Hey again,\n\u003e \u003e\n\u003e \u003e Otherwise Mallory gets two invoices, and wants to know if they're\n\u003e \u003e\u003e actually the same node.  Inv1 has nodeid N1, routehint Bob-\u003eC1, Inv2 has\n\u003e \u003e\u003e nodeid N2, routehint Bob-\u003eC2.\n\u003e \u003e\n\u003e \u003e I think this attack is interesting. AFAICT my proposal defends against\n\u003e this\n\u003e \u003e because of the way\n\u003e \u003e `payment_secret` and `decoy_key` are both used to derive the `decoy_scid`\n\u003e \u003e (but don't trust me, do\n\u003e \u003e verify that I'm not missing something).\n\u003e \u003e\n\u003e \u003e If Mallory doesn't use both the right `decoy_node_id` and\n\u003e `payment_secret`\n\u003e \u003e to compute `P_I`, Bob\n\u003e \u003e will not decode that to a valid real `scid` and will return an\n\u003e \u003e `unknown_next_peer` which is good\n\u003e \u003e for privacy.\n\u003e\n\u003e But Mallory can do the same attack, I think.  Just include the P_I from\n\u003e the wrong invoice for Bob.\n\u003e\n\u003e \u003e It seems to me that\n\u003e \u003e https://github.com/lightningnetwork/lightning-rfc/pull/681 cannot defend\n\u003e \u003e against this attack. If both invoices are currently valid, Bob will\n\u003e forward\n\u003e \u003e an HTLC that uses N1\n\u003e \u003e with C2 (because Bob has no way of knowing N1 from the onion, for privacy\n\u003e \u003e reasons).\n\u003e \u003e The only way I'd see to avoid is would be that Alice needs to share her\n\u003e \u003e `decoy_node_id`s with\n\u003e \u003e Bob (and the mapping to a `decoy_scid`) which means more state to\n\u003e \u003e manage...but maybe I'm just\n\u003e \u003e missing a better mitigation?\n\u003e\n\u003e No, Bob can include the scid he used in the update_add_htlc message, so\n\u003e Alice can check.\n\u003e\n\u003e I'm extremely nervous about custodial lightning services restricting\n\u003e what they will pay to.  This is not theoretical: they will come under\n\u003e immense KYC pressure in the near future, which means they cannot pay\n\u003e arbitrary invoices.\n\u003e\n\u003e Thus my preference for a system which doesn't add any requirements on\n\u003e the payer.\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200205/08571a4f/attachment.html\u003e"}