Combine this paper with the fact that half of all coins are hosted on networks controlled by two US entities

😬

Another reason to migrate to NIP 17 and stop using NIP-04s DMs, which have a similar issue.

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.

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

packet size flow wars

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. @The Tor Project has been using some padding methods + constant message sizes for covering its traffic for some time and @Mullvad VPN just introduced an option for that too.

Non KYC ISPs need non KYC ISPs. Let the SATs flow!

I remember back when this kind of data initially came out that @niftynei() 🇺🇸💸🧡 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.

Qual é o problema dos nodes LN estarem centralizados nas Big tech?

That argument never resonated with me. The number of hosts that obfuscate their IP is likely negligible.

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

used to shit on shitcoiners for doing this. bitcoiners are getting complacent

Not crazy at all.

I saw a lighting node called "HAMnoder" the other day, and I wondered if he was running it over HAM.

i run 3 nodes and they all pretend to be somewhere they’re not 🤷 sample size of one tho

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

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

Correct me if I'm wrong, but your ISP or an AS you cross still sees your traffic regardless of .onion?

Yes but the Tor/Sphinx protocol makes sure that all packages are the same size (in contrast to "pure LN")

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.

Add a little mixnet in there and you also get rid of the temporal correlation (feasibility still to be shown).

💯 for on-chain tx's that would be amazing to have.

I'm actually working on a defense for LN with less overhead.

Nice article! View quoted note →