what are the best resources to learn about these vunerabilities?
nostr:note1qqqy29072nvdvlqvx58wusuzd3uqekrtm74d8pprfqackeur78nqjzyta3
Discussion
there is a lot of researched published by the Tor project about the problem of metadata, and Tor is one of the best ways to mitigate useful information being available to such attackers
i wish we could upgrade tor so it has a market based funding mechanism for relay operators... i tried to build something https://github.com/indra-labs/indranet but funding ran out and i only got it to the point of having an effective source onion routed protocol that actually works, i haven't got it plugged into lightning network yet
This goes onto my list of projects that I want to fund, when I become rich lol. How much do you need to finish it?
i wouldn't know what it costs to finish it but 12k was spent to get it to that point... to actually finish it i think i'd need a front end dev and a lightning network specialist
there is a lot of research and development work required to find ways to improve the network intelligence required because it is a source routed protocol, but also, because it is a source routed network transport, it might be a bit easier to solve some problems in a similar way as tor's telescoping system, except modified to be a kind of a "telescope ping" so clients can be confident that paths will carry packets to the destination, and i also want to complete my ideas about making "fork and join" paths that have a higher cost but lower latency
i think if i had access to a good FE and LN dev i could have a good late beta working in a year
i remember first encountering teh idea of "agoric routing" in a discussion on the tor mailing list back in 2006 or so, and indra is basically my attempt to realise it, based on what i learned from studying the lightning network, which also facilitates funding relays to operate
there is lots of interesting stuff relating to it being a kind of "spam resistant" network protocol that protects anonymity while preventing spam
the other big problem that i have not done enough work on is congestion, how to avoid congestion, i know part of that might relate to the "telescope ping" idea but also how to help clients avoid picking congested paths in general, this is one of the things that TCP solves but it's hard to do with a source routed network, because clients can all roll snake eyes at the same time and try to send messages through that path and it hits a point that is overloaded
Regarding front end: I would have a look at ShipFa.st (currently using it, super simple boilerplate code)
Regarding Lightning: I would ask the guys at CLNs telegram channel: https://t.me/lightningd
Or LNDs Dev Kit: https://discord.gg/3GMMSgR5
2: could you explain, if/why the message system of Lightning is insufficient, to argue to hijack it for onioned data packages?
Have you looked into ecash? It's a simpler architecture that sits on top of lightning. nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg explains the design here. s/VPS/tor/g
nostr:note1h0qgrfmfuf2jm3jlqrmz3usxfvhktn9tl7jd4e0rf5r9y242ndlqthz67t
if you read the architecture spec of indra you will see that it uses the same source-routed onion layered encryption/forwarding scheme as lightning uses, except for with traffic
there is actually a "message" protocol in lightning nodes, this project was intended to be something like popping that out to the front and putting teh LN in the back as the way to limit spam and incentivise node runners
ecash is a client/server tech that was invented in 1983 by David Chaum, and while it has its uses, anonymity is NOT one of them, and i have had multiple harsh interactions with Calle about this, and he conceded i was right, ultimately mints know who mints and who redeems
the Indra protocol enables you to use Keysend or AMP payments (AMP is a multi path, failure resistant variant of route selection) that enable you to load your accounts anonymously with indra nodes without them knowing who you are, and you can do this with LN, you can't do this with ecash, or at least, the mint is a weak link in this process, lightning onion routing prevents the correlation in origin (it doesn't hide timing though, but this is the same in Tor as well)
i'm being polite because i assume you don't realise i've been involved with Tor since 2006 (look for David Vennik in the tor mailing list archives) and i gave up on Tor because they didn't want to talk about a way to monetise tor node operating, which i perceived as a long term vulnerability that would slow the expansion and thus weaken the security of the network
i haven't been wrong about that either, there has been several cases of breaches of anonymity on Tor, Ross Ulbricht is the most famous one
Ty that would be a correct assumption. :)
Agree, monetization of decentralized protocols is key. Without an economic incentive they will forever be niche and vulnerable. I'm working to create an economic incentive for btc block template production.
What do you think about other anonymizing network infra projects? I know bitcoin nodes can operate on clearnet, tor, I2P, and cjdns but I haven't studied them enough to understand the differences. I have heard about something else called nym, but it's run by a company 😒.
There is an alternate timeline somewhere where I dug in and became a btc p2p expert but that's not how the cookie crumbled.
haha, yeah, i got back to that timeline for 2023 but funding ran out and my sponsor was no kind of marketing genius, so we didn't find more funding
it's incredible how much work you have to do to simply get people who have capital to invest and a desire to invest it in a specific category of things to learn about it, they are constantly fending off bullshit, i'm sure, it's just like all network protocols...99% spam, 1% signal
as far as i can tell, tor is the most successful because it has the best balance of engineering tradeoffs, similar to how bitcoin is the winner for distributed ledgers
i've thought more about the subject recently, as regards to the way tor uses telescoping (my new term for this is "telescoping ping"), and honestly i didn't even touch the subject of distributing node information across the network, tor uses a centralised directory server for this, which is obviously undesirable, this seems like the right place to put a DHT, but there is all kinds of curly spam problems to navigatet to that destination as well
Whoa, that's cool. I don't totally get it but are you replacing BOLT12 onion routing with tor onion routing?
no. all lightning payments use TLV onions
i point this out to monero fans all the time and they don't get it
when lightning payments fail, it's usually because one of the hops in the chain (typically 5-7) is congested or offline... the receivers generate the receipts and they are a set of hidden instructions layered in multiple layers of encryption for how to forward the payment
adding the ability to do this with messages is just a matter of adding the mesage to the first layer (last to be decrypted, by the recipient)
i'm glad i taught someone something today
you can learn this in more detail by reading about how lightning network protocol works. Notably, look into lightning network messages and the sphinx protocol, which is the basis of lightning network payment routing
I'm well versed in lightning. There was interest early on to use LN as an anonymous message routing protocol a la sphinx chat. It kinda fizzled out, though. I think the expert consensus was that LN is a monetary network and attempts to use it for messaging run counter to it's intended purpose and create negative externalities.
If the tor node is bundled with a mint they can dox you if you connect directly to the mint. BOLT12 has very nice privacy properties. What if the mint accepts only BOLT12 peg-ins, no peg-outs, and receives ecash "postage" only via tor?
This creates an interesting situation where users need to first use lightning onion routing (bolt12) to buy ecash tokens to gain access to tor onion routing. Kinda convoluted but is it broken somehow?
i had no intention of doing invoicing on indra, keysend and AMP only, probably AMP due to it probably having a better pathfinding algorithm
that's the point!
i don't think you really understand it that the invoices contain an onion layered encryption that each node decrypts and reveals its part and forwards it on
indra does the same thing, except it's designed to do 3 hops and encrypt a single network transport packet
so it's like sphinx, but the real reason why the messaging part of LN never went anywhere is because it has no spam control or congestion control
by creating a micro account system paid for via keysend/AMP payments, the problem of spam is solved
i had not fully worked out schemes for congestion control, but there was an idea of propagating a network load state across the network to update the congestion state
i know about how latency and lag can affect schemes like this, it's not easy to avoid with this kind of protocol which was why i was starting to work on the idea of redundant multipaths
so i guess that would be like RAM routing, redundant atomic multipath, that forks out and back like lightning
Yeah there's a lot I don't understand about the proposal. Does it interoperate with vanilla tor nodes or is this a totally separate network? Are you paying each node on the onion route or just the end node? If it's just the end node, you are only incentivising tor exit nodes which is useful but I think a more general approach would enable paying routing nodes also.
With ecash you could literally include the ecash postage in each layer of the onion message. Each hop decrypts the next destination and the postage. Postage could be independently verified with DHKE and double spending prevented with p2pk locking. No extra network calls necessary. The tor node needs to trust the mint. Could be done with a whitelist like "I only accept postage from these mints."
For AMP or keysend on the tor network you don't have the capability to pay tor nodes along the onion route. Or if you do that is a separate lightning transaction for each hop. That would thoroughly destroy your latency, but I think LN's low payment reliability would be a bigger problem.
If it's a new network you could pay nodes along the route with standard lightning fees but now node operators have the additional burden of running a LN node on top of a tor node. That's a big lift for hobbyist node runners.
Oops I meant DLEQ not DHKE
Signal can reveal two pieces of information as far as I know:
1. the last time you were online
2. your phone number.
The phone number is my primary concern because governments can track your location by triangulating it through mobile carriers.
But can they read your data/messages? It's encrypted or?
Phone number is also my biggest concern. That’s why I prefer nostr:npub1exv22uulqnmlluszc4yk92jhs2e5ajcs6mu3t00a6avzjcalj9csm7d828
What if you use a VoIP number?
YOU SHOULD USE A VOIP OR BURNER NUMBER BUT MOST DONT.
IN SIGNALS DEFENSE THEY DO NOT ACTIVELY BLOCK VOIP NUMBERS LIKE MANY OTHER SERVICES.
You mean the last time you were not online?
Penis.
The best resource is to avoid them all together if anyone wants real private conversations. Good old fashioned meetups are the best. Otherwise, there’s always a backdoor to discovery. Depending on encryption methods, “they” will have to work harder to determine information. But give them enough time/technology and they’ll figure it out. If someone is a whale, you’re worth their time. If someone is a goldfish, they don’t have the manpower to be bothered.
With that said, if someone is adamant about the best digital privacy, simply be one step ahead. You need people on your team smarter than the people on their team. It’s that simple. Rather than focus on the vulnerabilities and try to fix them, Create better technology. Develop better algorithms. Design better encryption schemes. 8 billion people in the world. Get the better squad. May the best man/woman/(or government) win.
Bitcoiners
Insiders
Live life on the edge
look at OG nostr DM's. understand what you're leaking there. similar concept. timing. link analysis. node analysis with common edges and clustering. traffic flow analysis. combine several of these and you can paint interesting social pictures and activity histograms. oh, timing with IP, ie. he hits off this IP most of the day but then this other one during the evening, which can deduce pattern of life. link sharing for previews that have UTM's attached. probably many many more.
telegram
I am also trying to read some quality opinions or reports but finding none
You don't know about metadata tracking? Some federal asset you are!