📅 Original date posted:2022-06-08
📝 Original message:
Dear Tony,
Thank you for putting emphasis on this. I was actually waiting for someone
to publicly exploit this.
> The reason this is possible is because [...] currently channel IDs are
> based on UTXO's. Scid aliases may be the biggest benefit here, but the use
> of `unknown_next_peer` , `invalid_onion_hmac`, `incorrect_cltv_expiry`,
> and `amount_below_minimum` have been the biggest helpers in exploiting
> channel privacy.
>
Just for reference the exploit with short_channel_ids is known since 2019:
https://github.com/lightning/bolts/issues/675
Though it is nice you point out explicitly the use of error codes of
onions.
> By creating a probe guessing the Channel ID based on unspent p2wsh
> transactions, it's a `m * n` problem to probe the entire network, where `m`
> is utxos and `n` is nodes.
>
It is the main reason why I didn't do this. Though similar to you probing
ACINQ's node one could probabilistically learn which nodes tend to have
unannounced channels and gain some speedup by probing those nodes first.
Also wallets tend to have poor utxo management. So looking at the on-chain
signal one can probably guess for a p2wsh to which two nodes it might
belong and try them first.
These two strategies should reduce the number of tested nodes for a newly
seen p2wsh output significantly and probably make it feasible to probe the
network as new blocks come in.
With kind regards Rene Pickhardt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220608/08a200ad/attachment.html>;
René Pickhardt [ARCHIVE] /
npub1zl…d2k4w
2023-06-09 13:06:12
in reply to nevent1q…k6mf
Author Public Key
npub1zlxd3xlzjhq2ue03e5m5p2w6mp8v3dkhq5r39flsftjjsje04wvsdd2k4wPublished at
2023-06-09 13:06:12Event JSON
{
"id": "60bf5569a89ce76c35e9af93a0e698203ab17604cba4aae050391685415baa6d",
"pubkey": "17ccd89be295c0ae65f1cd3740a9dad84ec8b6d7050712a7f04ae5284b2fab99",
"created_at": 1686315972,
"kind": 1,
"tags": [
[
"e",
"1618107891053511544f6de09f3eea688dfa07aedf80db4d3c530a52a0cbd29b",
"",
"root"
],
[
"e",
"1c8212c16c2d2327edca5583431f5c502d618453870ebcfffee76275ed238816",
"",
"reply"
],
[
"p",
"ec660007cefcf8f82ee7f8700161858f8a698419823238586a465963611b30bd"
]
],
"content": "📅 Original date posted:2022-06-08\n📝 Original message:\nDear Tony,\n\nThank you for putting emphasis on this. I was actually waiting for someone\nto publicly exploit this.\n\n\n\u003e The reason this is possible is because [...] currently channel IDs are\n\u003e based on UTXO's. Scid aliases may be the biggest benefit here, but the use\n\u003e of `unknown_next_peer` , `invalid_onion_hmac`, `incorrect_cltv_expiry`,\n\u003e and `amount_below_minimum` have been the biggest helpers in exploiting\n\u003e channel privacy.\n\u003e\n\nJust for reference the exploit with short_channel_ids is known since 2019:\n\nhttps://github.com/lightning/bolts/issues/675\n\nThough it is nice you point out explicitly the use of error codes of\nonions.\n\n\n\u003e By creating a probe guessing the Channel ID based on unspent p2wsh\n\u003e transactions, it's a `m * n` problem to probe the entire network, where `m`\n\u003e is utxos and `n` is nodes.\n\u003e\n\nIt is the main reason why I didn't do this. Though similar to you probing\nACINQ's node one could probabilistically learn which nodes tend to have\nunannounced channels and gain some speedup by probing those nodes first.\n\nAlso wallets tend to have poor utxo management. So looking at the on-chain\nsignal one can probably guess for a p2wsh to which two nodes it might\nbelong and try them first.\n\nThese two strategies should reduce the number of tested nodes for a newly\nseen p2wsh output significantly and probably make it feasible to probe the\nnetwork as new blocks come in.\n\nWith kind regards Rene Pickhardt\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220608/08a200ad/attachment.html\u003e",
"sig": "e45208ab04fd3dff1dbc2e0de63f28c6a5b6a7e50d088c5128959e0d417b51c571bb97de188c1c8273b443a8f0c82ee95ce8be41c7eff7091aeb06630a837330"
}