<oembed><type>rich</type><version>1.0</version><title>Rusty Russell [ARCHIVE] wrote</title><author_name>Rusty Russell [ARCHIVE] (npub1zw…hkhpx)</author_name><author_url>https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2020-02-04&#xA;📝 Original message:&#xA;Bastien TEINTURIER &lt;bastien at acinq.fr&gt; writes:&#xA;&gt; That&#39;s of course a solution as well. Even with that though, if Alice opens&#xA;&gt; multiple channels to each of her Bobs,&#xA;&gt; she should use Tor and a different node_id each time for better privacy.&#xA;&#xA;There are two uses for this feature (both of which I started implementing):&#xA;&#xA;1. Simply always use a temporary id when you have a private channel, to&#xA;   obscure your onchain footprint.  This is a nobrainer.&#xA;&#xA;2. For an extra layer of transience, apply a new temporary id and new&#xA;   nodeid on every invoice *which applies only for that invoice*.&#xA;&#xA;But implementing the latter securely is fraught!&#xA;&#xA;Firstly, need to brute-force the onion against your N keys.  Secondly,&#xA;if you use a temporary key, then you *don&#39;t* end up using the HTLC to&#xA;pay an invoice matching that key, you *MUST* pretend you couldn&#39;t&#xA;decrypt the onion!  This applies to all code paths between the two,&#xA;including parsing the TLV, etc: they must ALL return&#xA;WIRE_INVALID_ONION_HMAC.&#xA;&#xA;Otherwise, Mallory can get an invoice, then send malformed payments to&#xA;Alice using the transient key in the invoice and see if she decrypts it.&#xA;&#xA;And then I realized that Alice can&#39;t do this properly without Bob&#xA;telling her what the scid he used to route was.&#xA;&#xA;Otherwise Mallory gets two invoices, and wants to know if they&#39;re&#xA;actually the same node.  Inv1 has nodeid N1, routehint Bob-&gt;C1, Inv2 has&#xA;nodeid N2, routehint Bob-&gt;C2.&#xA;&#xA;Now Mallory uses Bob-&gt;C2 to pay to N1 for Inv1.  If it works, he knows&#xA;it&#39;s the same node issuing both invoices.&#xA;&#xA;So, update_add_htlc needs a new scid field.&#xA;&#xA;At this point, I think we should just add a new channel_flag, which if&#xA;you set it (and feature flag is offered) you get assigned random SCID&#xA;from the peer in funding_locked.  This overrides your&#xA;funding-transaction-based SCID.&#xA;&#xA;That gets the first case for new channels, without adding much&#xA;complexity at all.[1]&#xA;&#xA;Thoughts?&#xA;Rusty.&#xA;&#xA;[1] If we want to cover existing channels, we need a new &#34;give me a&#xA;    replacement scid&#34; msg and reply.  But it can be idempotent (you&#xA;    only ever get one replacement).</html></oembed>