Whoa, that's cool. I don't totally get it but are you replacing BOLT12 onion routing with tor onion routing?
Discussion
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
i was so busy making a thing with what LN does to do payment routing that i had not realised for almost 3 years that most people, even technically skilled/educated folk, don't realise that lightning payments are encrypted in onion layers just like TOR
i hope lots of you read that and realise
i would love to finish Indra, most of all right now, to have a big pile of sats thrown at me (if only dispensed monthly on a schedule, that's fine) and finish the LN integration and actually get to see this baby running in the wild
it's tor, but where you can get paid to run a node
it will scale so much faster than tor and work better
i just have to thrash out details about how to increase transmission reliability because it has the same problems as lightning payments