Why Nostr? What is Njump?
2023-06-09 13:06:12
in reply to

Tony Giorgio [ARCHIVE] on Nostr: πŸ“… Original date posted:2022-06-13 πŸ“ Original message: Rene, Thanks for your ...

πŸ“… Original date posted:2022-06-13
πŸ“ Original message:
Rene,

Thanks for your reply.

> 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.

​
That was going to be one of my next steps. I thought about parsing through the data from https://github.com/lnresearch/topology in order to get a link between every unpsent p2wsh transaction up to 6 hops forward from the opening transaction between two nodes. Then keep a list of every node and their possible p2wsh transactions and probe with those. Should cut down a lot but I have not run through this dataset problem yet. Curious if you think that would be the best process moving forward with this.

Otherwise, going through LSP's with the assumption set, like I did with ACINQ would probably yield further results.

Regards,
Tony
------- Original Message -------
On Wednesday, June 8th, 2022 at 12:42 AM, RenΓ© Pickhardt <r.pickhardt at googlemail.com> wrote:

> 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/20220613/10ec2bcf/attachment.html>;
Author Public Key
npub1a3nqqp7wlnu0sth8lpcqzcv9379xnpqesgerskr2gevkxcgmxz7st7w4e3