📅 Original date posted:2020-02-04
📝 Original message:
Bastien TEINTURIER <bastien at acinq.fr> 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).
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:58:33
in reply to nevent1q…sxpq
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:58:33Event JSON
{
"id": "d41610f23f17847fb2730a3699fbbb7faad9cb79407ce468bc0f55d49144d043",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315513,
"kind": 1,
"tags": [
[
"e",
"3ed35742512a6038c8a47910d5915af4fefd8766015db6ab01e4ef19d4ac6fff",
"",
"root"
],
[
"e",
"c9112e55f1c265196b491fb57dd6fac352ddcafffba6462637be4bd4f7e17853",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "📅 Original date posted:2020-02-04\n📝 Original message:\nBastien TEINTURIER \u003cbastien at acinq.fr\u003e writes:\n\u003e That's of course a solution as well. Even with that though, if Alice opens\n\u003e multiple channels to each of her Bobs,\n\u003e she should use Tor and a different node_id each time for better privacy.\n\nThere are two uses for this feature (both of which I started implementing):\n\n1. Simply always use a temporary id when you have a private channel, to\n obscure your onchain footprint. This is a nobrainer.\n\n2. For an extra layer of transience, apply a new temporary id and new\n nodeid on every invoice *which applies only for that invoice*.\n\nBut implementing the latter securely is fraught!\n\nFirstly, need to brute-force the onion against your N keys. Secondly,\nif you use a temporary key, then you *don't* end up using the HTLC to\npay an invoice matching that key, you *MUST* pretend you couldn't\ndecrypt the onion! This applies to all code paths between the two,\nincluding parsing the TLV, etc: they must ALL return\nWIRE_INVALID_ONION_HMAC.\n\nOtherwise, Mallory can get an invoice, then send malformed payments to\nAlice using the transient key in the invoice and see if she decrypts it.\n\nAnd then I realized that Alice can't do this properly without Bob\ntelling her what the scid he used to route was.\n\nOtherwise Mallory gets two invoices, and wants to know if they're\nactually the same node. Inv1 has nodeid N1, routehint Bob-\u003eC1, Inv2 has\nnodeid N2, routehint Bob-\u003eC2.\n\nNow Mallory uses Bob-\u003eC2 to pay to N1 for Inv1. If it works, he knows\nit's the same node issuing both invoices.\n\nSo, update_add_htlc needs a new scid field.\n\nAt this point, I think we should just add a new channel_flag, which if\nyou set it (and feature flag is offered) you get assigned random SCID\nfrom the peer in funding_locked. This overrides your\nfunding-transaction-based SCID.\n\nThat gets the first case for new channels, without adding much\ncomplexity at all.[1]\n\nThoughts?\nRusty.\n\n[1] If we want to cover existing channels, we need a new \"give me a\n replacement scid\" msg and reply. But it can be idempotent (you\n only ever get one replacement).",
"sig": "774b7d1a24e6a819bbf5a910a70b965516cbedb08e2c352e1ebaf2dbe5c15ae0ab2d6d68050f899b470100a808f51e55b6cb81d56d2a6268fec97ca660113884"
}