Incentivized by the Bitcoin Lightning Network.
More decentralized. More Secure. Relays earn sats. Powered by Bolt12 offers.
151 sats \ 2 replies \ @anon 15 Jul
Pretty interesting. My first thought is that we would need to figure out how to avoid trolls that want to take payment and still block. But also less malicious, if a tor node goes offline or decides you are abusing their bandwidth, how quickly can you recover by recalculating a path seemlessly? What could be worse than no service is spotty or unreliable service, and with no rating system, you could just be throwing your money into the hands of the trouble makers.
Hmm, and then with automated payments, I imagine this will go through a few iterations to mature and become robust.
Really cool idea though!
reply
Thanks! Great point!
It is still early. Just the basic design and code.
Right now the design depends on the client paying the relays out of band for a 10 minute circuit. There is currently no way to guarantee the relays respect this. They could, for example, close the circuit right away and take your precious sats!
In the current design, an easy mitigation could be to pay only half upfront, during the the circuit build step and the other half after 10 minutes, on the circuit destroy step. This would incentivize the relay to keep the circuit open for 10 minutes. You could also keep a black list of unreliable relays and maybe gossip that info on some reputation network.
Another design idea is to use keysend in the data stream (instead of at the circuit build step).

Keysend Goal

Enable clients to pay relays using keysend, ensuring only the intended relay can access the preimage needed to claim the payment after they relay the traffic to the next hop.

Basic Concept

  • The client generates a random preimage and its hash.
  • The client encrypts the preimage using the public key of the first relay (Relay 1).
  • The encrypted preimage and hash are included in the onion-encrypted data passed through the relays.

Steps

1. Client

  • Generates a preimage P and its hash H.
  • Encrypts P with Relay 1's public key to create Enc_PK1(P).
  • Constructs the onion payload including the hash H and Enc_PK1(P).

2. Relays

  • Each relay decrypts its layer to forward the data, hash H, and encrypted preimage Enc_PK1(P).

3. Recipient Relay (Relay 2)

  • Processes the data and sends Enc_PK1(P) back to Relay 1.

4. Relay 1

  • Decrypts Enc_PK1(P) using its private key to retrieve the preimage P.
  • Verifies the payment by checking if hash(P) = H.

Security

  • Ensures only Relay 1 can decrypt the preimage using its private key, preventing Relay 2 or others from stealing the funds.

Will it work in practice?

This might be too slow in the real world though, since it would need to occur at the data stream. Also, not sure how many wallets support keysend currently. It might also be a receiver side privacy concern doxxing the nodes public key (do blinded paths and keysends exists?). Also, the client might try to screw over the relay and send fake payments, since the relay must forward the data stream onto the next hop before receiving payment. Not sure if there is a way to mitigate that with fancy cryptography.
But it would be a fun topic of research.
reply
142 sats \ 0 replies \ @anon 16 Jul
Ecash (esp. Locked to pubkey ecash) seems to fit really well with realtime use cases like this, but it also is a custodial model. More precisely it is custodial but does not compromise privacy at the sender level OR the receiver (relay) level.
Still, just like how when you make a trade p2p you might want an arbiter you both trust to resolve conflicts, if a relay broadcasts a list of trusted mints, and the client user also trusts one of those mints (they should be careful that the mint is not owned by the relay ideally for reasons...), then the client can purchase ecash upfront and send it with their tor packets with practically no latency cost because with pay to pubkey ecash, the tor relay only needs to check the ecash signature and the pubkey to know that the ecash is legit, and no one else could possibly claim the sats but themselves as the pubkey owner.
reply
Looks dope! A great use case for LN.
reply
reply
What is that search term "family:008EAE223B110C8EDEE20D06FB0DD4C43E3E0142"?
reply
333 sats \ 1 reply \ @C_Otto 16 Jul
If you run multiple nodes, all nodes must reference all sibling nodes - forming a so called family. This is used by clients so that each circuit only uses at most one of the nodes in each family. Otherwise, if more than one node of a family is used, the admin of these nodes might be able to gain insights into the user's traffic.
This search term uses one of the nodes' IDs and queries for all nodes that belong to the same family - i.e. nodes run by me.
reply
Makes sense. Thanks for the answer. 210 sats earned and sent.
reply
Great.
It was only a matter of time until someone built this.
What's the compatibility like to the rest of Tor? Separated networks? Or using regular Tor as "0 sats" nodes?
reply
Great. It was only a matter of time until someone built this. What's the compatibility like to the rest of Tor? Separated networks? Or using regular Tor as "0 sats" nodes?
Probably a fork. Still early days. Code and architecture here https://bitbucket.org/eltordev/eltor/pull-requests/1
reply
How easy is it to run a relay anonymously? Device spec etc? Would be keen to help out
reply
Not sure what is meant by "anonymously" but you would be putting your IP address up in the Directory list (thats just how Tor currently works). For example, @C_Otto shared his Tor relays in the post above #609650
A really cool goal to work towards is to popularize more use of "Tor Hidden Services". Right now its hard to visit a .onion site because the names are not human readable. For example in "Clearnet" if you goto https://google.com it looks up via DNS the ip address 142.250.114.100.

The idea: Gamer Tags (Onion Short names)

It would be cool to build a similar human readable naming system for "short onion addresses". For example mapping stackers news onion address http://snsnsnya6h3ot563f3p566wuhfoklkg5f62hokdlaqzcaub3gf4xlxyd.onion to something like http://crazyhorse69.onion.
There are several ways to do this, but it would be nice to do it in a decentralized way. Bitcoin is decentralized and we all already own sats. So maybe we could create a deterministic list of words (and maybe a few numbers) to create a "gamer tag" like crazyhorse69.
The deterministic list can be an imaginary overlay, ordinally ordered list, that maps each "gamer tag" to a single satoshi (sort of like the original ordinal theory that Casey pitched) but with more human readable names. We would simply just need to mash up enough words (and a few digits) to make 2.1 quadrillion "gamer tags" that map to each individual satoshi. (sort of like we have a standard list of words that go into your BIP-39 seed phrase https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt)
Then anybody who already owns satoshis already has a basket of "gamer tags" they can choose. They they can simply sign a message with that key for the mapping. Really anything can be mapped. Doesn't just have to be onion addresses
reply
It seems to me that Bitcoin is going to incentivise so many services like this that legacy finance didn't work for. Just a matter of time.
reply
🤙FYI stackers: will be forwarding over sats to @eltordev wasn't sure earlier if she wanted to be doxxed
reply
Just relays or also exit nodes?
reply
yep exit nodes too. an exit node might want to charge a higher rate for this service due to more risk sharing his public IP addresses. Some mitigation could be running OpenDNS on the exit node. The Tor project has few blog posts on best practices running an exit node.
A cool novel idea is to only run the exit node when you are on public shared wifi like a coffee shop (is wardriving still a thing lol). Not sure how this would exactly work but maybe a dedicated app could be built using privacy tools like mac address spoofer, etc..
reply
Entry guard, middle relay, and exit relay. Watch the video again. You seems just reading
reply
It this why normal Tor is flaky recently?
reply
Tor is ran by volunteers around the world. There is a finite amount of bandwidth for everybody to share. A lot of the relays are funded by human rights organizations (which is great) but also there is no real incentive for a Pleb to run one at home (outside of good will). There is also no way to prove if the majority of nodes are from malicious actors (think deep state) trying to correlate traffic (albeit hard to due). Introducing an incentive will spark a free market of relay operators. Further increasing bandwidth and decentralization.
In regards to a "slow" wallet using tor....if you infrequently open a lightning wallet (particularly on mobile) it might seem slow to start because tor has to sync the directory of relays from the Authority relays (since IP addresses change and the network is always changing). After it gets an updated list of relays it need to build a circuit (typically 4-8) relays. This takes a short amount of time. After that, the circuit typically lasts 10 minutes and subsequent payments should seem faster.
Also, some of the recent flakiness may be due to this: https://x.com/lopp/status/1812500211681370484
reply
I run a lightning node in hybrid mode, and my tor-only peers much more often go offline than clearnet ones. I guess guard tor nodes are throttling them.
Do you have a way to track how many free relays switched to paid?
reply
not yet, the code is still in the early design and research phase
reply
14.9k sats \ 1 reply \ @eltordev 17 Jul
deep state took the video down. here is a new link https://www.youtube.com/watch?v=smS18ZO9fes
reply
fookin legend!
reply
thanks for building this .. an important new channel of progress to explore in this important ecosystem .. given value in privacy that Tor itself seeks to deliver, subsequent use of eCash could also help here .. but underlying concept of incentivising relay runners should help both network breadth and speed
reply
Oh man. This should make it to the SN podcast.
reply
Great work right here man. Makes me wanna run a relay now.
reply
What the hell?
YouTube are a bunch jamokes.
reply
I just saw that when I sent a comment in a Live stream on YouTube on a bitcoin podcast, the comment that I made about El-Tor was immediately muted and never seen by anyone else in Live Stream Chat. So it appears they have a filter set up against it. Them trying to silence it this quickly tells me that it must be something worth looking more into.
reply
This is huge! Sounds like a great use case for LN! This is only for relays?
reply
ty for sharing!
reply
Thanks! Looks great!
reply
Very cool!
reply
Thanks greaat points
reply
noice!
reply
Love it. Ties everything together for me. Now open source server nerds can promote freedom internet and make money, not just freedom money on the internet. Looking forward to using it!
reply
Is a nice idea for improving Tor but I will still do not recommend LN nodes over Tor and will not connect to ANY Tor only node. Never!
reply
https://github.com/Indra-Labs/indra Cool architecture. I read the whitepaper. But it appears very ambitious and possibly abandoned. Tor has existed for over 20 years. Has good funding and a strong community. The codebase is solid and well audited. So simply shimming "lightning" in the code was very low hanging fruit to pragmatically solve the problem. It is not trivial creating low level routing software that can handle high bandwidth from scratch (especially in a well suited programming language like C) . Might as well use what already exists. Bolt12 offers (with blinded paths) was really the catalyst to make this fairly easy to do
reply
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.
stackers have outlawed this. turn on wild west mode in your /settings to see outlawed content.
deleted by author
reply
deleted by author
reply
ah makes sense
reply