Hi Tony,
> The reason this is possible is because probing is a free operation on the
> Lightning Network after a channel is opened, the error reasons given are way
> too verbose, and 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.
Can this be fixed by making error messages less verbose or reveal less
information?
> We should definitely migrate to alias scid's, and encourage every active
> unannounced channel holder to close, coinjoin, and reopen with an alias. But
> care should be given in the future when it comes to error reasons revealing
> information that is meant to be "private". Until this migration happens, it
> would be beneficial to stop being so specific about errors, this does not
> really seem to help end users anyways.
Alias SCID would be better for privacy as they allow a node to request a
channel by a random value instead of value derived from the on-chain
transaction. Are alias SCIDs necessary to fix it or error messages alone can
fix it?
I found these pull requests and assuming alias SCID are already implemented in
LDK/rust-lightning:
[https://github.com/lightningdevkit/rust-lightning/pull/1311/](https://github.com/lightningdevkit/rust-lightning/pull/1311/commits)
https://github.com/lightningdevkit/rust-lightning/pull/1351
> I'll be continuing with this probing project while the problem exists, and
> work on narrowing down the other channel partner and fixing efficiency bugs.
> I am publicizing the results as I go, so fair warning that if you have any
> unannounced channels that you assumed were private and need them to be, close
> them now on the off chance they get revealed. This could have always been
> happening already already by analytic firms, so I hope by publicizing this we
> are all on the same playing field. It is also beneficial to get a better
> estimate of the unknown size of the Lightning Network.
I love the research and thanks for sharing all the information. I am assuming
analytic firms would be using this already.
/dev/fd0
Sent with [Proton Mail](https://proton.me/) secure email.
------- Original Message -------
On Wednesday, June 8th, 2022 at 7:35 AM, Tony Giorgio via Lightning-dev
<[email protected]> wrote:
> Hi,
>
> For the past few months I have been working on an LDK probing project that
> searches for unannounced channels on the Lightning Network. For the past
> week, I have been probing on mainnet and squashing bugs / making
> optimizations.
>
> So far I have found near 445 unannounced channels totaling 1,076,077,750
> satoshi's locked across the 3 nodes I have probed, some with just a minimized
> set (~30,000) of probable channels based on "round payment amount" and "1 or
> 2 tx output" heuristics on P2WSH UTXO's. Most of them being on Aincq's node
> found with the minimized set, I've yet to run the complete set with them.
> There are about ~860,000 P2WSH UTXO's, about ~60,000 of which are public, so
> the upward limit of possible private channels is around ~800,000.
>
> The exact results are publicized here:
> https://github.com/BitcoinDevShop/hidden-lightning-network/blob/master/data/results/results.json
>
> The reason this is possible is because probing is a free operation on the
> Lightning Network after a channel is opened, the error reasons given are way
> too verbose, and 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.
>
> 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. Without these errors and instead something like
> `temporary_channel_failure` or a generic indistinguishable error, guessing a
> Channel ID would come down to an upwards of `m * n * n-1 * ~2000`, which
> would be each utxo with each pairing of nodes, each with about ~2000 cltv's
> to guess (numbers are as low as 7 to as high as ~2000). I threw the extra
> 2000 into the equation because even with `800,000 * 1 * 2000`, it gets much
> more time consuming to even probe a single node when we're already spending
> upwards of a day or so for near 1 million or 2 probes. Concurrent probing is
> possible, but starts to require more locked up liquidity.
>
> We should definitely migrate to alias scid's, and encourage every active
> unannounced channel holder to close, coinjoin, and reopen with an alias. But
> care should be given in the future when it comes to error reasons revealing
> information that is meant to be "private". Until this migration happens, it
> would be beneficial to stop being so specific about errors, this does not
> really seem to help end users anyways.
>
> I'll be continuing with this probing project while the problem exists, and
> work on narrowing down the other channel partner and fixing efficiency bugs.
> I am publicizing the results as I go, so fair warning that if you have any
> unannounced channels that you assumed were private and need them to be, close
> them now on the off chance they get revealed. This could have always been
> happening already already by analytic firms, so I hope by publicizing this we
> are all on the same playing field. It is also beneficial to get a better
> estimate of the unknown size of the Lightning Network.
>
> For more about this project and viewing the dataset, go to
> http://hiddenlightningnetwork.com
>
> Thanks,
> Tony
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
