From rusty at rustcorp.com.au Tue Feb 4 04:04:31 2020 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 04 Feb 2020 14:34:31 +1030 Subject: [Lightning-dev] Decoy node_ids and short_channel_ids In-Reply-To: References: <87h808cml7.fsf@rustcorp.com.au> Message-ID: <87o8ufatgw.fsf@rustcorp.com.au> Bastien TEINTURIER writes: > That's of course a solution as well. Even with that though, if Alice opens > multiple channels to each of her Bobs, > she should use Tor and a different node_id each time for better privacy. There are two uses for this feature (both of which I started implementing): 1. Simply always use a temporary id when you have a private channel, to obscure your onchain footprint. This is a nobrainer. 2. For an extra layer of transience, apply a new temporary id and new nodeid on every invoice *which applies only for that invoice*. But implementing the latter securely is fraught! Firstly, need to brute-force the onion against your N keys. Secondly, if you use a temporary key, then you *don't* end up using the HTLC to pay an invoice matching that key, you *MUST* pretend you couldn't decrypt the onion! This applies to all code paths between the two, including parsing the TLV, etc: they must ALL return WIRE_INVALID_ONION_HMAC. Otherwise, Mallory can get an invoice, then send malformed payments to Alice using the transient key in the invoice and see if she decrypts it. And then I realized that Alice can't do this properly without Bob telling her what the scid he used to route was. 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. Now Mallory uses Bob->C2 to pay to N1 for Inv1. If it works, he knows it's the same node issuing both invoices. So, update_add_htlc needs a new scid field. At this point, I think we should just add a new channel_flag, which if you set it (and feature flag is offered) you get assigned random SCID from the peer in funding_locked. This overrides your funding-transaction-based SCID. That gets the first case for new channels, without adding much complexity at all.[1] Thoughts? Rusty. [1] If we want to cover existing channels, we need a new "give me a replacement scid" msg and reply. But it can be idempotent (you only ever get one replacement).