{"type":"rich","version":"1.0","author_name":"npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","author_url":"https://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-02-04\n📝 Original message:\nBastien TEINTURIER \u003cbastien at acinq.fr\u003e writes:\n\u003e Hey again,\n\u003e\n\u003e Otherwise Mallory gets two invoices, and wants to know if they're\n\u003e\u003e actually the same node.  Inv1 has nodeid N1, routehint Bob-\u003eC1, Inv2 has\n\u003e\u003e nodeid N2, routehint Bob-\u003eC2.\n\u003e\n\u003e I think this attack is interesting. AFAICT my proposal defends against this\n\u003e because of the way\n\u003e `payment_secret` and `decoy_key` are both used to derive the `decoy_scid`\n\u003e (but don't trust me, do\n\u003e verify that I'm not missing something).\n\u003e\n\u003e If Mallory doesn't use both the right `decoy_node_id` and `payment_secret`\n\u003e to compute `P_I`, Bob\n\u003e will not decode that to a valid real `scid` and will return an\n\u003e `unknown_next_peer` which is good\n\u003e for privacy.\n\nBut Mallory can do the same attack, I think.  Just include the P_I from\nthe wrong invoice for Bob.\n\n\u003e It seems to me that\n\u003e https://github.com/lightningnetwork/lightning-rfc/pull/681 cannot defend\n\u003e against this attack. If both invoices are currently valid, Bob will forward\n\u003e an HTLC that uses N1\n\u003e with C2 (because Bob has no way of knowing N1 from the onion, for privacy\n\u003e reasons).\n\u003e The only way I'd see to avoid is would be that Alice needs to share her\n\u003e `decoy_node_id`s with\n\u003e Bob (and the mapping to a `decoy_scid`) which means more state to\n\u003e manage...but maybe I'm just\n\u003e missing a better mitigation?\n\nNo, Bob can include the scid he used in the update_add_htlc message, so\nAlice can check.\n\nI'm extremely nervous about custodial lightning services restricting\nwhat they will pay to.  This is not theoretical: they will come under\nimmense KYC pressure in the near future, which means they cannot pay\narbitrary invoices.\n\nThus my preference for a system which doesn't add any requirements on\nthe payer.\n\nCheers,\nRusty."}