Payment Censorship in the Lightning Network Despite Encrypted Communication
The authors demonstrate how to detect LN messages by their deterministic sizes and packet flows. These methods allow a network-level adversary to identify and censor payments in the Lightning Network.
😱
Paper: https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.AFT.2024.12
Combine this paper with the fact that half of all coins are hosted on networks controlled by two US entities
oops
😬
We need lightning over #LoRa and #meshtastic and #ham.
Another option: we crowd fund a small satellite constellation. Sounds crazy but as the price of bitcoin goes up it becomes more affordable for our community.
Not crazy at all.
I saw a lighting node called "HAMnoder" the other day, and I wondered if he was running it over HAM.
Lightning over LoRa is not going to work, lightning has far too much overhead and LoRa has really (really really really) low bandwidth (the noisefloor magic aint free). You could use another PHY, but then still you are just spinning a whole lot of wheels to get a simple transaction through. Future potential softforks might make it a bit better.
Something like ecash makes more sense; even then you might want to consider if the overhead is worth it given you are dealing with such heavy technical (and legal/regelulatory) constrains working within the lower frequency ISM band options; combined with the inherrent inefficiencies of the mesh topology
#Reticulum
packet size flow wars
I remember back when this kind of data initially came out that nostr:nprofile1qyxhwumn8ghj7cnjvghxjme0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpz9mhxue69uhkummnw3ezumrpdejz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3jamnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kz7qgwwaehxw309ahx7uewd3hkctcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qfrwaehxw309ahx7um5wgkhvetjd9nxjety9emk2mrvdaexgetj9ehx2ap0qylhwumn8ghj7mn0wd68ytt4wdsju6mpx9nkyet0vyerzcnwd5h82uedwajhxapdxghxxuewv9kkz7n0dekxjemgw3ekz6tv9e3k7mf0qy2hwumn8ghj7mn0wd68yt35xvuxytnwv46z7qpqe0z776cpe0gllgktjk54fuzv8pdfxmq6smsmh8xd7t8s7n474n9snrh2rn mentioned it was not really accurate due to the ability to make it seem like your node is hosted on one of these when it's not.
I'm not really technical so I can't really explain it, though the number of nodes that aren't actually hosted on these is probably quite small overall.
However I think this is a symptom of the quite relaxed environment LN is on rn, I believe if attacks were to start happening this hosting data would change quite a bit.
It's like bitcoin mining, if under attack it decentralizes more and more, otherwise it takes advantage of the friendly environment.
This is pretty misleading, as it shows nodes, not capacity, and excludes Tor.
There’s also the fact that at least for a lot of the smaller share ones, they may be used just for proxying for a public IP.
Not that this means anything as if it is shut down, new nodes can come up to replace them in other networks
Pretty sure the number of servers doing that is so small that it's irrelevant. I've never seen any data to convince me of the opposite.
Even if, it wouldn't matter since we're talking about network use here not where the server is located.
used to shit on shitcoiners for doing this. bitcoiners are getting complacent
Another reason to migrate to NIP 17 and stop using NIP-04s DMs, which have a similar issue.
Run #LND? get a #TOR running partner
#lightning #privacy #research
Payment Censorship in the Lightning Network Despite Encrypted Communication - Charmaine Ndolo & Florian Tschorsch, 2024
"5.2 Towards a solution
...
The purpose of doing so is to utilise Tor’s implementation of WTF-PAD and not for Tor’s privacy properties. We issued payments in both directions, closed the channel and finally the TCP connection. Not only did all packets have the same packet length (as is expected when using Tor), but the flow of transmitted packets included packets that did not originate from the application.
Consequently, we were not able to detect which packets belonged to which Lightning message by manually inspecting the capture. The rule-based state machine is therefore no longer capable of distinguishing application messages based on the network traces alone. In fact, we conjecture that this approach offers a high degree of protection for
the LN against more sophisticated fingerprinting techniques by network-level adversaries as basically all size and timing features are destroyed.
...
Specifically, we concurrently captured the packets sent locally between the LND node and the Tor SOCKS5 proxy, as well
as the packets sent between the Tor process and Tor network. The former provides data on the packets that actually come from the application while the latter provides data on what a network-level attacker would observe. The captures show a total of 14, 824 bytes transmitted
in 379 TCP packets to/from LND and 929, 596 bytes in 3191 TCP packets to/from the Tor network. This equates to an increase of ≈ 6170% in bandwidth when using Tor. The captures also show a peak rate of 0.116 Mbit/s when using Tor, which clearly should not cause any problems for LN nodes while maintaining their current hardware configurations."
This is true for all encrypted traffic even Tor. But for LN it's especially revealing given the known message sizes and strict order of messages.
nostr:nprofile1qqszr7k0w6gclv3usnqmey68uzs6h2yt7dpw2dyeqt0sh8ehaxl8xyqpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qz9thwden5te0v35hgar09ec82c30wfjkccte89v5nr has been using some padding methods + constant message sizes for covering its traffic for some time and nostr:nprofile1qqsdru78zcu6uwa6zlludjx7k87m8ft9q6e5jgsn6qe49rxzj9frwpqpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qz9thwden5te0v35hgar09ec82c30wfjkcctehznuka just introduced an option for that too.
Non KYC ISPs need non KYC ISPs. Let the SATs flow!
Monero solves this!
Qual é o problema dos nodes LN estarem centralizados nas Big tech?
Nice to know they conclude, "We analyse countermeasures the network can implement and come to the conclusion that an adequate solution comprises constant message sizes as well as dummy traffic. "
