rich1.0npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxhttps://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://nostr.ae📅 Original date posted:2020-02-04 📝 Original message: 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.