Nostr Web Client

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?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

Reply to this note

Please Login to reply.

Discussion

vnprc 1y ago

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.

vnprc 1y ago

Oops I meant DLEQ not DHKE