pull down to refresh
151 sats \ 2 replies \ @anon 15 Jul \ on: El-Tor: High Bandwidth⚡️Tor Network Release! builders
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!
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
Pand its hashH. - Encrypts
Pwith Relay 1's public key to createEnc_PK1(P). - Constructs the onion payload including the hash
HandEnc_PK1(P).
2. Relays
- Each relay decrypts its layer to forward the data, hash
H, and encrypted preimageEnc_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 preimageP. - 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
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