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
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
