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