Tor Idea.

[slush]

Why?  Even CPU mining will generate a result in under a minute.  GPU mining would have you going in seconds.

Who said that one submitted share per minute will be enough for premium bandwidth? It's less likely with rising difficulty...

Also, "even CPU mining" - say this to people who have one share per one hour. And I don't believe chinese disidents have strong GPU rigs in their basement :-).

Actually redeemable codes have two main advantages:
* You can premine them, no need to wait to mining submits during tor session
* Price for transfer don't need to be same as "submit rate on common computer" to keep Tor running.

Disadvantages:
* There's some central entity (anonymous pool). However some pool will be still necessary, as relays don't want to mine solo, probably. And routing getworks and shares between pool and tor user over the relay is just another complication and overhead...

How will you prevent double-spending the codes without accounting?

Of course relay redeem the code on issuer application, but it's very easy to implement. Actually my "no accounting" was related to issuing side; tor users don't need any account on pool issuing redeemable codes.

[1715038219]

1715038219

[1715038219]

1715038219

[1715038219]

1715038219

[1715038219]

1715038219

[1715038219]

1715038219

[Revalin]

And I don't believe chinese disidents have strong GPU rigs in their basement :-).

They'll have to make due with the free TOR net which will hopefully be faster once all the pirates or whatever switch to premium nodes.

* There's some central entity (anonymous pool). However some pool will be still necessary, as relays don't want to mine solo, probably. And routing getworks and shares between pool and tor user over the relay is just another complication and overhead...

Agreed on the advantages; I don't think this disadvantage is a deal killer.  This part is the problem:

Of course relay redeem the code on issuer application, but it's very easy to implement.

Sure, it's a simple DB of used codes...  But the table will be HUGE, require a unique key constraint (not a good combination), and it will have a constant stream of inserts from every relay node.  You can go distributed at the expense of some double-spends, but it's still going to be large and grow rapidly.

[hashman]

And yes, paying for access wouldn't make Tor any more resistant against the Chinese government, I know.

If you had to pay for the information about a relay it would make it harder (more expensive) to find relays and block their IPs.

[BTCurious]

And yes, paying for access wouldn't make Tor any more resistant against the Chinese government, I know.

If you had to pay for the information about a relay it would make it harder (more expensive) to find relays and block their IPs.

i.e.: China would pay its inhabitants to run Tor nodes, and occasionally switch IPs.

[Mike Hearn]

I think the user experience of requiring mining would be very poor. Consider the common case of people who only own laptops (like, er, me). Mining is never going to fly in such a setup.

I don't understand the concern with just paying nodes via regular Bitcoins, or using the micropayment protocol described here:

https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly_adjusted_.28micro.29payments_to_a_pre-determined_party

Yes, you can't connect to the nodes directly to handle such payments, but integrating it with the Tor protocol would probably be an interesting project that could be accepted back into the mainline network. You'd have to do the setup as part of establishing the circuit. After that you can just send the new transactions to the relays/exit nodes as you use traffic. After a while the Tor nodes broadcast the last seen transactions and lock in the payments.

It's quite feasible to break outputs up such that it's hard to correlate them back to the same user. There are Java implementations of Tor and you could grab some unused cell IDs to extend the protocol.

[Revalin]

I don't understand the concern with just paying nodes via regular Bitcoins, or using the micropayment protocol described here:

The problem is anonymity.   TOR provides much stronger anonymity than Bitcoin. If you don't need that you can just use VPN services which are already available for BTC.

[zer0]

And yes, paying for access wouldn't make Tor any more resistant against the Chinese government, I know.

If you had to pay for the information about a relay it would make it harder (more expensive) to find relays and block their IPs.

China's creepy firewall immediatley detects a local user connecting to a bridge, then blocks it a few seconds later
https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors

[stochastic]

And yes, paying for access wouldn't make Tor any more resistant against the Chinese government, I know.

If you had to pay for the information about a relay it would make it harder (more expensive) to find relays and block their IPs.

China's creepy firewall immediatley detects a local user connecting to a bridge, then blocks it a few seconds later
https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors

I was in China during the month of December and could connect fine.

[Mike Hearn]

The problem is anonymity.   TOR provides much stronger anonymity than Bitcoin.

I disagree with that analysis.

Each Tor node creates its own key to receive payments for a particular circuit. You select some coins from your wallet, say at random, and use a different output from a different tx to pay each node, possibly creating some pay-to-self transactions to achieve that. It's not obvious from the block chain, nor any of the commands sent to the ORs, how to link these payments together, and even if you could do it that doesn't result in you learning the origin IP of the user anyway. The nodes take responsibility for broadcasting the final TX.

If somebody can outline an attack on the scheme I just outlined, I'd like to see it.

[Revalin]

If you make a bunch of micropayments from one wallet, they're trivially associated.  If you want to use multiple nodes you'll have to source clean coins from different sources for each one.  If one of the people who sells you coins gives you up (subpoena, rubber hose, whatever), you're compromised.  Even if they don't it makes it much easier to associate all your previous connections together, which may compromise you.  Bitcoin is pseudonymous, not anonymous, and there are many practical ways that people with resources can unveil you unless you are very careful and take a lot of precautions.
https://en.bitcoin.it/wiki/Anonymity
http://anonymity-in-bitcoin.blogspot.com/2011/07/bitcoin-is-not-anonymous.html


TOR by comparison makes it so there are multiple nodes in different countries routing your data.  Each time you start up (and any time you want) it builds a new tunnel with different nodes, leaving no connection to your prior identity.  It's very strong anonymity, and it makes it very easy for anyone to get that level of security.

Bitcoin's anonymity isn't anywhere near as easy and robust.

[Mike Hearn]

If you make a bunch of micropayments from one wallet, they're trivially associated.

No they're not, no more than any other bitcoin payment is.

You can have two transactions, from different source addresses, in your wallet. There are no rules stating you have to combine them. Satoshis code will do whatever is most efficient, but you can easily have alternative rules that prioritize obfuscation or privacy if you want.

I think it's quite possible to split up large outputs into a bunch of smaller independent transactions that use keys which are then destroyed, meaning it cannot be proven that it was you who generated them.

Bitcoin is pseudonymous, not anonymous, and there are many practical ways that people with resources can unveil you unless you are very careful and take a lot of precautions.

The same is true of Tor. These are privacy enhancers, not guarantees. They're usually "good enough".

I know how Tor works by the way. You can still be unmasked through a variety of esoteric and not so esoteric attacks. And if you're using hidden services you can probably be compromised via something as trivial as phishing.

[Tuxavant]

As a TOR exit operator (tn3t.com), I feel like a dirty whore for even thinking this up...

But it would be possible to throw up a garden on my exit nodes with a bitcoin donation page. Once my costs were covered, I could "release the hounds".

The reality is, I'd love to throw up more exit nodes, but for now, I can only afford two, nearly all personally funded, nodes.

[ForceField]

I just started the TOR Relay Project thread.

As mentioned, I would like to set up a Tor Relay Access node for the benefit of Tor users and require some input from the bitcoin community.

[cunicula]

After reading the thread, it seems like the best method is to pay the nodes via mining, and then have the nodes submit work to mining pools of their choice.

The alternative is to keep a permanent record of who paid who in a blockchain. A permanent record seems bad for two reasons:

1) Possible revelation of identities associated with pseudonymous accounts

2) Large informational overhead associated with record of micro payments, particularly if there are many single-use accounts issuing micropayments.

(1) and (2) are related because (2) may be caused by users desire to avoid (1).


Mining on the other hand does not require preservation of an identity record because the payment is in the form of a rivalrous good (you can't use the submit the same work twice, double spending is a non-issue). You can't tell whose computer work came from.

The requirement that people have some kind of GPUs is not steep. People who use TOR often have this type of stuff anyways. People who want high bandwidth TOR could afford an entry level GPU (~US$70 or so). High bandwidth is not necessary for Chinese dissidents. It is more for IPR pirating purposes.

The requirement that the nodes communicate work to pools does not seem steep either. It seems like a pretty simple thing for the software to do.

A remaining problem is cheating. Nodes might prefer to capture work before users detect that they are not providing bandwidth. Users might prefer to get bandwidth before nodes detect that they are not providing work. To avoid these outcomes, I would suggest some time or informational exchange barrier to establishing a productive routing relationship. (i.e. make the users and nodes waste some time/bandwidth at the outset) This type of investment would make maintenance of the connection valuable to all the nodes and the user. Cheating would not be profitable.

[runeks]

I'm with Mike Hearn on this one. I see no reason that Bitcoin transactions couldn't be exchanged in a way that preserves anonymity.

Requiring the user to have a GPU in his computer makes the mining approach stillborn, in my opinion. We all agree that it will have limited use, but I think it simply will not have enough users to become widely adopted. Laptops running on battery would be more or less useless - any mobile device would be useless: the battery would be drained in no time. We would depend on AMD's proprietary Catalyst driver in order to even utilize the GPU, or Nvidia's proprietary driver in case you can accept even lower efficiency per watt spent.

I acknowledge that it's a challenge to separate a user's identity from a Bitcoin address. Presuming that we have to get the bitcoins from an exchange, there will probably be a public record tying our name to that address. This needs solving.
A possible solution could be a built-in bitcoin tumbler/mixer service that simply returns X BTC from a stranger's address when you send X BTC to the service. Even if this proves untenable, I think we would be able to provide a solution. I mean, Bitcoin addresses are no more that data, it's as easily forgotten as the data you receive over the Tor network. The problem seems to me to be the interface between the current system (banking, credit cards) and the Bitcoin system. A Bitcoin tumbler seems like a possible solution to this issue.

[cunicula]

I'm with Mike Hearn on this one. I see no reason that Bitcoin transactions couldn't be exchanged in a way that preserves anonymity.

Requiring the user to have a GPU in his computer makes the mining approach stillborn, in my opinion. We all agree that it will have limited use, but I think it simply will not have enough users to become widely adopted. Laptops running on battery would be more or less useless - any mobile device would be useless: the battery would be drained in no time. We would depend on AMD's proprietary Catalyst driver in order to even utilize the GPU, or Nvidia's proprietary driver in case you can accept even lower efficiency per watt spent.

I acknowledge that it's a challenge to separate a user's identity from a Bitcoin address. Presuming that we have to get the bitcoins from an exchange, there will probably be a public record tying our name to that address. This needs solving.
A possible solution could be a built-in bitcoin tumbler/mixer service that simply returns X BTC from a stranger's address when you send X BTC to the service. Even if this proves untenable, I think we would be able to provide a solution. I mean, Bitcoin addresses are no more that data, it's as easily forgotten as the data you receive over the Tor network. The problem seems to me to be the interface between the current system (banking, credit cards) and the Bitcoin system. A Bitcoin tumbler seems like a possible solution to this issue.

These objections make very little sense. How important is it to do your TOR browsing where you don't have access to an outlet? Does it matter that AMD makes drivers any more than it does that seagate makes hard drives? Is TOR widely used outside of geek communities that have GPUs anyways? The user just needs the hardware, he doesn't need to know a thing about bitcoin or deal with an exchange. The nodes would do that. I think this actually allows for wider use, GPUs are much more widespread than familiarity with bitcoin.

Consider the argument on the other side. Bitcoin isn't anonymous unless you are extremely careful. That's a core issue affecting the whole function of TOR.

Finally, why not do both? A less secure solution involving bitcoin would appeal to some. A more secure solution that involves submitting mining work would appeal to others.

[Revalin]

I see it as degrees of anonymity.

TOR provides that every session is isolated, and a new identity can be taken at any time with little cost.  This provides a very strong level of anonymity, say 9 out of 10.

The bitcoin micropayments method would mean that a central authority that receives those payments would have knowledge to at least say that sessions 1, 2 and 3 were performed by the same account.  It's easily believable that a secret court order could be made to require them to keep such logs.  As such, the anonymity guarantees are weaker, say 5 out of 10.

It's plenty good enough for people who want to post to Bitcointalk.org anonymously, but inadequate for people trying to overthrow a totalitarian regime.  Providing a solution that anyone can easily use, AND feel confident that it's strong enough to stand up against the resources of a major government, is important for TOR.

[runeks]

(I'm replying to a comment from this thread because they pertain to the same subject)

A central party sells redemption codes that can be exchanged for bitcoin. The codes are micro redemption codes, so maybe 10000 codes = 1 bitcoin. Users purchase the codes in bulk and stream them to nodes. The nodes redeem the codes with the central party for bitcoin. The use of disposable coupons keeps bloated microtxns out of the blockchain.

I do think a central authority would make it a lot easier to administer. As I understand it, the Tor network isn't distributed anyway, so it makes sense to have a central authority that handles payments as well.
Again, the critical point at which an identity could be revealed would be when purchasing redemption codes for bitcoins. We still lack an official way to sever the link between an exchange address (which can be tied to your identity) and some new address. Bitcoin tumbler?

Also, we would need to immediately delete these redemption codes upon being spent. This, unfortunately, can leave traces on a hard drive if the data ever reaches this place. But trying to mitigate this before having a working solution seems unnecessary.

The central party will know the pseudonymous identities of users and nodes, but not their real identities. To make it a business, the central party can skim some off the top.

Yes. I imagine every connection ever made in this scheme will be made trough the Tor network. I mean, we're using the Tor network already, if we don't route *all* connections through Tor it seems to make little sense in the first place.

These objections make very little sense. How important is it to do your TOR browsing where you don't have access to an outlet? Does it matter that AMD makes drivers any more than it does that seagate makes hard drives? Is TOR widely used outside of geek communities that have GPUs anyways?

I think they are relevant objections that will hinder its adoption.

• 1. Why would we beforehand exclude mobile devices from using this service? This seems like a poor design choice to start out with, if you ask me. Especially in a world where the mobile device is quickly replacing the traditional PC.
• 2. Yes, depending on drivers owned by AMD is very different from Seagate making hard drives. It would be analogous to actually depending on another party's property in order for the solution to work (the driver is owned, in part, by AMD, along with all the comapanies from which AMD license code). The solution would depend on AMD lending out its driver for use in this project. That seems to be another unfortunate design choice to start out with.
• 3. I have no idea who and how many people use Tor (and that's the way it should be). If we assume that 10 million people use Tor, and there are, maybe 10,000 bitcoin miners in the world, how many of these bitcoin miners also have a need for Tor? Not many I reckon. We would be severely limiting the user base if we target only geeks.
  

I like you idea of redeemable codes purchased with Bitcoins much better.

[runeks]

The bitcoin micropayments method would mean that a central authority that receives those payments would have knowledge to at least say that sessions 1, 2 and 3 were performed by the same account.  It's easily believable that a secret court order could be made to require them to keep such logs.  As such, the anonymity guarantees are weaker, say 5 out of 10.

You're right. It would be ideal if we could keep it decentralized. The chain will only be as strong as its weakest link.

[Revalin]

Thus why I like the idea of mining for bandwidth so much. 

I'm still hopeful that someone can find a way to allow direct payments while preserving strong anonymity, but that's been worked on by the larger Bitcoin community for quite a while without much success.  Mixer pools are about the best so far, but they're only like a 4 or 5 out of 10 right now (not enough people using them) and maybe a 6 or 7 if they become widely adopted.  It's a pretty tough problem.

Even with the current state of things, there's still some room between the 2/10 anonymity of VPNs and the 9/10 of TOR+GPU where perhaps a micropayment-mixer system could be useful.