rich1.0npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxhttps://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://nostr.ae📅 Original date posted:2020-02-10 📝 Original message: Bastien TEINTURIER <bastien at acinq.fr> writes: >> 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). Yes, I've added this to the PR. Which gives a new validation path, I think: ## Figuring out what nodeid to use to decode onion 1. Look up scid from HTLC; if it didn't include one, use default. 2. Look up payment_hash; if no invoice is found, use default. 3. If invoice specified this scid, get nodeid and use that. 4. ... and refuse to forward the HTLC (it must terminate here). My plan is to add an argument to `invoice` which is an array of one or more scids: we get a temporary scids for each peer and use them in the routehints. We also assign a random temporary nodeid to that invoice. The above algo is designed to ensure we behave like any other node which has no idea about this nodeid if Mallory: 1. tries to use a temporary node id on a normal channel to us. 2. tries to pay another invoice using this temporary node id. 3. tries to probe our outgoing channels using this routing hint (I think we should probably ban forwarding to private channels, too, for similar reasons). --- Note that with any self-assigned SCID schemes, Alice has to respond to unknown scids in update_add_htlc with some BADONION code (which makes *Bob* give Carol an error response, since Alice can't without revealing her identity). With Bob-assigned SCIDs, Alice simply needs to make him unallocate it before forgetting the invoice, so she will simply never see old invoices. (All these schemes give limited privacy, of course: Bob knows who Alice is, and fingerprinting and liveness attacks are always possible). > 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. 1>> > > 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. Not if ln_strike (no, the other one!) is the future. > 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). Actually, as long as the same method is required for both normal private channels (which will all use non-tx-based short_channel_ids in the near future I hope!), I don't really mind. I expect such payments to become significant, and as long as paying to a temporary id and paying to a private channel looks identical, it's too draconian to ban. A business would probably meet any KYC requirements by simply asking the user (perhaps over a certain amount, etc). (I've put my implementation on hold for a moment while I'm supposed to be releasing 0.8.1-rc1 RSN!) Cheers, Rusty.