Bitcoin Forum

Hi,

I really like Bitcoin and have been becoming more and more interested in Tor with Sopa and Acta being discussed. But Tor is quite slow, which I think is due to a lack of relays.

I was thinking of a way to inventiveize being a relay. One idea I had, also I should preface that I don't have much tech experience so don't know how realistic my thoughts are, but I thought that the Tot client could make users do some Bitcoin mining, then for all the mined coins to be distributed fairly between those that act as relays.

Not sure how many use Tor in order to be even capable of competing with pools to get coins to be worthwhile for relays.

Again, just an idea from an uninformed user.

Best,

R

My gut reaction was: no way is this going to happen, mainly because people who mine usually want the Bitcoins for themselves. On further reflection, I think this isn't quite impossible to get working - maybe in the TOR userbase there are people who'd be willing to part with some GPU cycles to support the system, even if they wouldn't be interested in mining as such. I think you'd have to make it voluntary, though, with the TOR installer / executable asking the user if they're willing to mine, and my feeling is people tend to say no when they're asked to do something extra.

In other words, there may well be a bunch of people who'd go for this, but whether it's big enough to justify the effort, I don't know. The biggest problem is, you'd probably have to get it included into the TOR client, which is likely to be an uphill battle as it would probably seem somewhat tangential to their actual focus.

That's an interesting idea.  I wouldn't make the clients mine, though.  Not everyone has access to a reasonable mining rig.  Just have the clients pay BTC for premium bandwidth.  For instance, offer to pay 0.001BTC per MB of transit.  That's highly profitable for the relays - it's a 100x markup over premium internet transit.  And it'd be a reasonable price for many users who want to go fast.

The two problems I see: 1, you'd have to prepay for your bandwidth, though that's not so bad when you can do very small microtransactions with BTC;  2, if you get your BTC from a non-anonymous source it defeats the purpose of TOR.  Clients who care could mine their own; most won't care since they're not worried about a threat strong enough to trace the coins back.

I understand that people who mine want to keep them for themselves, but I saw this as more of a 'fee' for using Tor and rewarding those to give services to Tor i.e. you pay with GPU cycles which can be anonymous I assume also many usign Tor are from oppressive regimes where they may not be able to afford fiat currency payments. I accept it is tangential to Tor's aim and would be uphill to get them to include it, but they idea was to increase the usability of Tor by making it beneficial for people to act as relays.

Well that's good idea. I would happily pay for premium bandwidth. Getting coins from anonymous sources would hopefully become easier in future when BTC becomes more widespread. You could meet someone and pay cash or whatever.

R

Having given it a bit more thought, I don't think paying BTC for MB-transit would work.  Paying every relay node from the same wallet would break TOR's anonymity completely.  Effectively you may as well pay a single node for VPN service, which is already available for BTC.  The only way around it would be to have hundreds of wallets to pay each relay node separately and that just isn't practical.

So I think I like your original idea of paying with mining.  You could simply connect through the TOR net as usual, except along each hop you get_work for mining.  Each share you submit will buy a small amount of bandwidth - say, 100 KB per share.

This would work well in several ways: 1) it preserves anonymity, since each get_work is completely independent and ephemeral; 2) it's much faster since submitted shares are instantly good, whereas regular transactions take time to confirm; 3) it avoids having to prepay in relatively large blocks to avoid excessive transaction fees.

Having done a bit of mental math, CPU mining would be marginally usable.  Your average speed wouldn't be very good but you could prepay ahead a little and get fast bursts as you need them - typical web surfing would probably work fine, much better than TOR is now.  And anyone with a GPU would have all the bandwidth they'd reasonably need...  They could torrent over TOR.

So in short, your idea is good, and you had it right from the start.  Now you've got me thinking about other ways that mining shares could be used as microtransaction currency.

Users can choose to mine and get better connection from the relays (who earn the coins) or choose not to and maybe get the usual slow connection?

That's the idea.  More likely it would be two tiers of nodes: fast ones that require the fee (and can therefore afford tons of bandwidth to service as much traffic as possible), and the regular nodes that provide free service (and are pretty slow because tons of people are using them for everything).

I think some sort of pool hosted as a tor hidden service, then use tor to send the
new blocks to workers and proof of work back doesn't need to be extremely fast.

The "fee" being the clients computer doing a little mining, correct?

The bottleneck in TOR is just that more nodes are needed? More of the special exit nodes specifically?

Can exit nodes be configured to only help customers who have signed with a certain key?

Yes.  Just like a mining pool you would get work then submit partial results as proof that you're performing the work.


Yes.  There is only a limited supply of people willing to donate free bandwidth for other people's anonymity.  There are enough that web browsing is usable but slow.  If it generated enough revenue to cover bandwidth costs, I bet there would be a ton more relay nodes.

Authenticating to exit nodes would weaken the anonymity unless your credentials are short-lived.

So....like a company that allows you to anonymise what sites you're visiting, that allows you to pay in bitcoins for the bandwidth.  Like a proxy....or "virtual private network"....


By rough count there are around 30 companies that do that on the main bitcoin website.


https://en.bitcoin.it/wiki/Trade#Connectivity (https://en.bitcoin.it/wiki/Trade#Connectivity)

TOR provides better anonymity than VPNs / proxies.  It relays through three nodes: the entry node doesn't know what you're visiting; the exit node doesn't know who you are; and the middle node prevents the other two from being able to compare notes.  Placing those nodes in different countries prevents them from being compromised by court orders to log traffic, for example.  It's also advantageous that each of your connections can't be traced back to a single payment address.

This is probably relevant http://cs.gmu.edu/~astavrou/research/Par_PET_2008.pdf

I just read the abstract.  That's good stuff if it works.  I'll read the rest of it when I get a chance.  Thanks.

reminder:bitcoin isn''t anonymous but can be made so

I think there are premium tor nodes right?

I thought only the exit nodes are slow right? ... Because they block some access, for example to the clearnet

I'm glad that people at least some potential in the idea. I would love to see Tor's quality increase. As I said I haven't enough know how to pursue this myself. But if people did see potential I am will to help in whatever way I can. I can contribute to a bounty, that's probably my only useful skill in this regard. :-) Unless there's need for an EU Banking Lawyer.

Slush already runs a hidden service for miners on his pool via Tor.

p2pool works fine over tor too

There have been some ideas, where you could "incentivize" tor relays and exit nodes with bitcoin payments. This would be awesome idea. However, not that easy to implement. Maybe we will see something similar to it though someday.

Can't see this working as it would weaken anonymity.

The best ways to improve Tor are:
-running a relay
-promoting its use

There are experimental P2P systems where traffic is exchanged as a currency. Bittorrent also has a loose currency basis (ratios). Improvements in this area would be something to do with Tor only and unrelated to bitcoin. You don't want to integrate them and most importantly you don't want to establish traceable links between both accounts.

The advantage of integrating it with bitcoin is the fact that bitcoin is a generic currency, that may be traded for anything else. With a "bandwidth currency", all you can is trade bandwidth for bandwidth. With a generic currency, people who want to consume bandwidth can pay with other means, while those who have the means to provide more bandwidth can earn something else from it. Basically, it is the advantage of money over barter. Unless, of course, your 'bandwidth currency' can also be traded as money, but then you're just creating a new digital currency - why not use the best one we already have available? ;)

Some discussions on this topic have already happened on these boards. I'm trying to find them, if I do, I'll come back and edit this post with a link. The greatest technical challenge is to make really tiny payments. You can't embed multiple bitcoin transactions inside each tor packet.

EDIT: Here's the topic; https://bitcointalk.org/index.php?topic=53551.0;all

You're making some big assumptions and stating them as fact.  I'm pretty sure that a simple, workable scheme to pay for transit with mining hashes can be made without compromising anonymity.

I'm skeptical that paying with BTC directly would work, but I'm not done with the paper linked above yet.  They're doing a pretty good formal analysis of the idea from what I've read so far.

Sure, if you take the "integration" part away and provide an anonymity layer then something viable is possible. It then would also by possible via cash or any other form of exchange...

My point is that any kind of "Tor reward scheme" would be mainly a Tor thing, and any relation with BTC wouldn't be natural. Sure, you can pay in BTC as you can pay in BTC for many other things.

The assumptions I made there were just taking the original proposal in this post in its most direct implementation. I was actually going to reply to your first post but then you posted almost exactly what I was going to reply.

BTW I'm going to start a relay at home today. Had it in the past, didn't care too much about it lately... but now I'm realising again it's very important and this post just reminded me.

EDIT: typo

Mining directly for Tor relay won't work very well, for many reasons. Firstly, you cannot communicate with relay directly, because it leaks your real identity (IP), so you need to build circuit to the hidden service linked with the relay and you need to do this for every relay you want to use in the future. It's not easy and definitely not elegant.

However the idea of "mining for bandwidth" _is_ pretty good. I agree that using Bitcoins directly for paying for bandwidth isn't anonymous enough for common users, although it still may work good enough for some users (not everybody care about 100% anonymity, many of Tor users simply need to avoid IP limitations etc).

My basic proposal is following (it can be extended in many ways, but I want to describe main idea):
1. Anonymous mining pool with slightly different interface; pool will return unique redeemable code for every submitted share instead of accounting 0.000001 BTC on some user's account. Miner can change identity (use different Tor circuit to pool hidden service) every few minutes, so pool have no link between issued redeemable codes.

2. Relay publish some contract about premium bandwidth to Tor relay directory (public list of Tor relays).

3. Tor client has its automatic circuit manager, which can be turned off easily. Instead of buildin defaults, custom circuit manager should pick information about premium bandwidth nodes from tor directory and build circuit using preferred relays. Tor client should pick few redeemable codes for every relay in future circuit and encrypt them using relay's public key (already exists in tor relay directory) and ask entry node to route those encrypted codes to relay during building the circuit.

4. Every relay during building the circuit will receive redeemable codes and redeem them against the issuer (link to issuer's API should be as a part of the data). If redeeming is succesfull, relay should use premium bandwidth for given circuit.

In this way, using premium circuits might be really anonymous, because there's no identity leak. Also extending the protocol should be pretty straighforward; only distributing of encrypted redeemable codes must be implemented into the currect Tor protocol.

Principle of redeemable codes can be pretty flexible, too. When some people don't care about anonymity so much, they can  "trade" bitcoins for redeemable code with some issuer hidden service. In this way, user is as anonymous as much used coins are laundered. There's also identity leak because issuer knows which redeemable codes are linked together (because they were traded for some bitcoins in one operation). Of course this can be obfuscated somehow (one guy can buy X codes from some issuer and then sell them anonymously for drugs or guns on SL, so drug dealer can use premium bandwidth on Tor and his identity isn't linked to any coins used for buying redeemable codes).

There are still some problems:
* Tor relay can accept redeemable codes, but don't provide promised service quality.
* Although Tor relay need constant amount of coins per MB (relaying is not affected by Bitcoin difficulty), rising Bitcoin difficulty can make this concept useless for common people without strong mining rigs.
* Using specific relays may be pretty insecure. Until premium bandwidth will be provided by the majority of the network, attacker can provide significant count of premium relays, so there will be pretty big chance that both entry and exit node will be under the control of the attacker. However this can be solved (for example) by paying for premium bandwidth only on exit node, because exit node is usually the bottleneck.

I agree with you, using bitcoins directly isn't sounding idea, because bitcoins have serious problems with anonymity. However bitcoin mining is pretty elegant way how to obtain some valuable item anonymously. So bitcoin(mining) + intermediate layer for distributing the value in the tor network (redeemable codes in my proposal) + Tor should work pretty good.

Not sure if it is exactly in line with OP idea but I saw in this forum another suggestion for monetizing TOR relay nodes. 

In addition to the problem of not enough relays there is the problem that relays announced publicly can be found by those that would wish to block them, which is regluarly done and effects users e.g. behind the great firewall.   

By charging a small amount for the relay info such attempts to block access to sites from TOR exit nodes or to block people connecting to relays would become more expensive. 

 

There are Tor bridges, private relays who're not published on tor router list. They're acting as entry nodes and it works for users behind Great Firewall pretty well. Btw it is possible to ask them directly for "premium bandwidth contract" even without extending the Tor protocol.


That won't work, it will just block regular users from using Tor if they won't be able to "pay" for router list. Once you have some access to Tor network, you can detect all exit node IPs in one hour using simple script. That's also the reason why Tor relay list is publicly accessible, because every attempt to hide it is "security by obscurity".

Is it possible to only pay the tor entrance node in bitcoin? That one already knows your IP anyway…

seems like this could be sortof implemented by the tor exit nodes putting up a donation address on the webserver tehy run on the exit IP. Then people who use the service could donate to them.

Yes, it is possible, but there's no big benefit in it, because usually the bottleneck is exit node, not entry node. Also by paying only for entry nodes, you're revealing that you're the client, which is leaking useful information for malicious nodes.

Yes, donating exit nodes is in my opinion the most important, because it's much harder to run exit nodes than classic relay (you need to fight all those DMCA calls, for example).

If you simply want to donate for building better Tor infrastructure, then feel free to send few coins to torservers.net, they're doing really good job for Tor. But if you want to "donate" for specific exit and then use some premium bandwidth, you still need changes in Tor protocol to auth yourself as a donator...

AFAIK, the great firewall had blocked bridges. Tor is unusable inside of China.
After all, to block bridges, all they've got to do is pay some people to spend the day on the Internet, creating google accounts and requesting more bridge IPs...

Finally, if you want to see ideas on how to monetize Tor relays, you should really take a look on the thread started by Mike Hearn that I linked above. Here's the link again: https://bitcointalk.org/index.php?topic=53551.0;all

Maybe, but there's simply no algorithm how to spread entry IPs between honest people and don't give it to China government :-). Paying for entry IPs isn't a solution, China still have much more money than chinese disidents.


What exactly you want to apply from Mike's proposal here? I think he's solving slightly different problem.

He's solving the problem of how to pay independent, anonymous and untrusted routers for the job of routing your packets.
Tor relays are just like routers. The same technique discussed there could be applied to the Tor network, taking the appropriate measures never to leak identity. I'm just not sure if it would really help (if people are willing to pay, if the offer of a few cents would motivate more people to set up a relay etc).

And yes, paying for access wouldn't make Tor any more resistant against the Chinese government, I know.
But if such protocol is implemented and it works, it could be used by mesh networks one day, once the hardware is good enough. That could be interesting, and could help fight censorship.

I imagine it as an incompatible fork of TOR.  When you go to build the circuit, nested tunnels are created to each successive relay node.  At that time you're already communicating with those nodes, so adding getwork/submit results into the protocol wouldn't be hard.





This would require centralized accounting.  If the codes are completely independent it would be a LOT of bookkeeping.  If the codes are pooled on an account that's used for a few minutes at a time, each account could only be used with one relay node, AND only when connecting to that relay node through a specific path.  That's a lot of complexity to add.

It would increase setup time since you would have to mine for several minutes to connect to the first node, then several minutes for the next node and so on.

If you allow premining or saving unused credits, it would also eliminate one of TOR's protections: forward secrecy.  If you save the account number on your computer, someone who logged your connection from an exit node would then be able to prove it was yours after seizing your computer.

For all those reasons I think it's better to mine in realtime for each node, only accumulating credits for as long as your tunnel is up.





This is a concern for any of the proposals.  Looking at it in a bigger picture than difficulty: you're providing value (a certain amount of security for Bitcoin) in exchange for value (transit).  Your hardware will be able to contribute less value as time goes on.

Net effect: the amount of transit you can afford with a given piece of hardware decreases.  However, an average PC only gets more powerful with time.  Right now you could probably mine in realtime for a reasonable amount of bandwidth even on a CPU.  In the future even low-end GPUs will suffice.  If ASICs happen and even GPUs become irrelevant, TOR-mine users will be able to buy a low-end HashASIC for $50.  For those who simply can't afford it, there's always the regular free, slow, TOR network.

I can imagine that my proposal can be compatible with current Tor and it's even less complex than "every relay is mining pool". Actually the only chance in your idea is "premine" traffic in every circuit, so you'll need to wait long time (hours?) before you'll be able to actually use the circuit. Don't forget that circuits are usually short-time constructs...



No... why? getwork() -> mining -> submit() -> redeemable code received. Miner can even choose target difficulty of getwork, so one redeemable code can be the equivalent of 100 shares, for example (with target in getwork set to 100). No bookkeeping, no accounts, no identity revealed. Every getwork can be as anonymous as in your proposal, except that you can freely premine codes independently on the circuits you'll want use in the future.


...because you didn't catch the idea of redeemable codes. No account is needed on the pool. Every getwork can be isolated, so you can get completely unlinked pieces of value (=redeemable codes, which are equivalent of some well-defined work on the pool). However you're right that once you'll use redeemable code on one relay, you should not use it on another. But it's ok, because one code can be 100kB of transferred data.


No; that's the basic improvement against "mine on the relay". You can mine overnight for codes and then use them all during your one-hour session when you actually need it.


No, once you redeem the code, you drop it, because it is useless; relay will redeem it's whole value.


I hope that I explained it better now :-)

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




Yes, you're describing the "completely independent codes" scenario.

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

Screw Tor, incentiveize a mesh network.  

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...


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.

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. :)




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




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.

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.

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.

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.

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.

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.

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.

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.


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.

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.

I just started the TOR Relay Project (https://bitcointalk.org/index.php?topic=63407.0) 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.

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.

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.

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.

(I'm replying to a comment from this thread (https://bitcointalk.org/index.php?topic=63533.0) because they pertain to the same subject)

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.

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.

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.

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

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.

Can you elaborate on how to arrive at these levels of anonymity?

What if we connect to the mixer via Tor and enough people are using it?

The numbers aren't metrics of any kind.  They're just arbitrary "star ratings".

VPN is a 2 - good enough for trolling web forums, but instantly compromised with a subpoena

Mixers are a 4 - it requires a lot of work to analyze usage patterns; a subpoena lets you definitively associate a whole bunch of IDs but you still have a lot of effort tracing the coins back to an individual.  But it's not impossible for someone with resources.

TOR is a 9 - It's easy to see that you downloaded TOR, and it's easy to see that someone using TOR did something, but connecting them is nearly impossible - the connections deliberately go through multiple countries and no centralized accounting is required anywhere, so even if one node is compromised it can't be traced farther.  There are still some weak attacks (like timing attacks) which is the only reason it's not a 10.




Connecting to the mixer isn't the hard part.  Here's how it goes:

1.  You buy 2.3456 BTC for cash from Alice.
2.  Alice sends 2.3456 BTC to 1xxx01 (your dirty wallet)
3.  1xxx01 sends 2.3456 BTC to the mixer.
4.  The mixer spits out 2.3456 BTC to 1xxx02 (your clean wallet, which you only use through TOR)
5.  1xxx02 sends 2.3456 BTC to 1xxx03 (your deposit address on BitTOR)
6.  BitTOR credits your account for 2.3456 BTC.
7.  You connect through BitTOR and your client sends a crypto sig to EN1 (exit node 1) to withdraw credits from 1xxx03 as you surf.

So what happens when The Man wants to find out who posted unauthorized pictures of the revolution?

They bust down BitTOR's door and find that 1xxx03 was the responsible party;
And look here, 2.3456 is a pretty easily traced amount all the way back to Alice.  You're busted.

OK, so split the amounts on the mixer service - 2.3456 in, 1.3456 out in one transaction to 1xxx03; 1.0000 change back to you at 1xxx04.  Now it's much harder to trace you back...  But that 1.0000 change is someone else's dirty money.  If you spend it anywhere that can be linked to you, you get dragged in for their crime.  That's no good.

If you send it to 1xxx03, they can now add the coin values and infer back up the chain.

If you send it to 1xxx05 (another BitTOR account), you now have to be careful not to use those two accounts together in any way.

You can keep sending it through the mixer, but the end result is your inputs - fees = outputs.  If few people are using the mixer, correlating them is easy unless you spend a LOT on fees and allow very long delays between inputs and outputs (to allow more mixing).

If the mixer's web page (where you get your deposit address) is compromised, you're busted.

If a decentralized mixer is partially compromised, your security goes down - each trip you take through the mixer increases the chances that your funds are cleaned by a compromised agent.

In short:  It's complicated, and while mixers improve anonymity, they don't provide strong guarantees.  It's better than shuffling your coins to a bunch of your own accounts and hoping no one realizes they all come from the same root (which is futile; that kind of trace is easy), but if I was betting my freedom, I'd want "very good", not "better".

If authorities can arrest and prosecute anyone without proof, why don't they just do that to Tor users? They can easily outlaw Tor in China, and, as you mentioned yourself, the ISP has logs of what the user has downloaded.

But you have a point, which is that a public log of all Bitcoin transaction exist; there is no such thing for Tor. I do imagine that if we mix well enough, and with a large number of mixes, it will be practically impossible for anyone to figure out what happened in that giant soup of transactions.
Of course fees will be charged; there's a price for anonymity. Much like surfing the web with Tor is slow (though we're trying to solve this).

I do think a heavily used distributed mixer would work well (and multiple rounds are obviously necessary). Why does it matter if "my" coins travel by an adversary? If we repeat the process several times, we can make sure that an attacker would need to control a significant amount of the nodes in order to do any damage. That's the risk of any distributed system.

I'm wondering if it would be possible to implement a secure, distributed Bitcoin mixer...

I really think this is a great perspective. There are multiple market segments to target. Both bitcoin coupon codes for bandwidth and proof-of-work for bandwidth have compelling use cases.

Now if there were only a group of interested, skilled individuals who would set these technologies...

So, just a bit of math to set things in perspective:

IP transit is about $5/Mbps per month == 321 GB / $5 == 64GB / $1

Mining (current difficulty = 1.4M) is about .022 BTC per 1 MHps-month

At 5.5BTC/USD, that's about $0.12 per 1 MHps-month

Therefore, 1MHps-month == $0.12/month * (64GB/$1) == 7.68 GB/MHps-month == 25 Kbps / MHps

So let's say you're using an midrange computer from several years ago: Core 2 Duo.  That will give you about 2MHps == 50Kbps == 0.375 MB per minute.  That doesn't sound like much, but realize it happens in bursts.  That's enough to have 60 seconds of reading time, then .375 MB delivered quickly (instead of waiting for TOR) when you click the next link.

... Which is not nearly as good as I had hoped, but it's still somewhat usable.

A low end (or laptop) GPU will do 25 MHps, which would let you do 4.7 MB per minute.  That's pretty respectable when used for web surfing bursts.

For reference, TOR is typically about 10-50 KB/s = 0.6 - 3 MB per minute.  That's dominated by latency, so most of what you'd be buying for premium is to have your short burst-requests handled first.

All told I'd say it makes an OK case for mining for bandwidth.  I figured it would be much better.  Direct payments for bandwidth would be easily economical though if the anonymity can be worked out.

Yes, the CPU numbers are not good. The low end GPU you cite is quite low-end, and even that yields maybe 80 kb/s in your calculation. The average computer gamer would have a GPU several times more powerful. Likely enough to stream video. Certainly enough to allow convenient downloading of large files.

The implication is that the market is limited to people who have a GPU (likely common among casual TOR using geeks) or people who are willing to purchase one (affordable given a strongly motivating use case).
For example, the Chinese government uses TOR for communications within their spy network. I'm sure they would drop the $100 for a GPU. This is not bad.

Let's say you get 5BTC back from the mixer that was previously used by someone to buy machine guns.  The BATF busts down your door, searches your place, and takes your computers.

They won't convict you for weapons trafficking, but they might find that you have the BitTOR account which was used to leak some diplomatic cables - which is what you were actually doing on TOR.  They then hand you off to the secret service or FBI or whoever deals with that stuff.

Or it could be that you were just using BitTOR for trolling a web forum.  You won't be convicted of anything, but you still have a busted door, no computers, a couple months wasted in jail, and $30,000 of legal bills.




It's a great idea, but I haven't seen it taken farther than "wouldn't it be great if..."

25MHps is very low for Radeons, but there are also a lot of GeForces out there, so I'm estimating low on purpose.

Mind your bits and Bytes (lower and upper B).  The low-end is 78kB/s == 625kb/s. 




Keep in mind that this is to be used in bursts - the idea is that you have enough saved credit over the last minute to instantly load a web page when you need it.  Even the CPU miner might marginally cut it for that, and the low end GPU would be plenty.

It's also useful for anyone who is willing to set it up, let it premine overnight, and then have it ready to go in the morning.

A botnet operator has HUGE incentive to implement it and use botnet resources to earn money supporting TOR network. Also, Bittorrent plus Bitcoin plus TOR sounds wonderful.

I like the idea so after seeing you guys having the brainstorming session open i wanted to give my 2 satoshis.

Implementing bitcoin micro-payments and the tor network anonymity is not a trivial task but not impossible either. So i went to research some info on the tor protocol and ended reading on the design paper (https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf). After examining the "4.2 Circuits and streams" section it came to me that OR (onion router) would be able to implement this without hassle if some core developers pick up on the idea.


So what if Bob includes a new bitcoin address in that response. The maximum cell size is 512 bytes so it shouldn't have any problem doing that in his first response to Alice. OR could talk to bitcoind on the local rpc interface and fetch a new address every time it has to build a new circuit, not reusing any of them, they are interested doing that to maintain anonymity too.
At this pace Alice could have the circuit open through 3-4 or any number of OR's including exit node with a unique payment address for every one of them. She can make a payment too all of them with only one transaction and start using the increased bandwidth with the first bitcoin network confirm of it. OR's could have their rates published in the public directory like for ex. 1 mBTC/10minutes or 1µBTC/1000 tor cells and Alice be able to establish circuits according to her needs.

This can be polished even further though, what do you think ?

That instantly proves that Alice is the same person on every OR she just paid.  That's not good.  It saves on fees, though.  :)

It's better than the "redeemable codes" idea in one way: if the redeemable codes are issued (and redeemed) with a central server, that's a very vulnerable point.  With your method, the list is public in the blockchain, but at least she's only compromised on exit nodes that cooperate with Mallory, instead of every node calling in to redeem a code.  That's worth a little thought.

yes, you're right but given that bitcoin would be implemented on such a low level no one will be able to tell who are the other nodes she paid for bandwidth. Remember that OR can't associate identities with a virtual circuit. Bitcon addresses are just a public key hash that can be appended in the initial payload along with the other hash that ORs already send.
Separate transactions could be made by Alice to prevent anyone know the number of nodes she passed through at any given time. The OR owner would have to "clean" their coins before spending them too just in case anyone was careless enough to pay from an identifiable address.

All this process can be easily automated only by configuring tor daemon to talk with the bitcoin daemon or wallet, restricted on the localhost. Interesting indeed.

Is it possible to combine the centralized coupon system and the mine-for-bandwith system through the mining pools somehow?

Lets say I connect to a big mining pool through free-tor. There I buy 9 BTC of future proof of work for 10 BTC (the pool make a profit of 1 BTC). When I need more bandwith from the TOR-network, I ask the nodes for a bitcoin adress each, give these adresses to the pool which distributes it to its miners, and provide me with the hashes. I give the hashes to the TOR-nodes who accepts them as payment. The TOR nodes don't know anything about each other, and the mining pool only know the bitcoin adresses that belong the TOR nodes I use, but can't associate the adresses with the nodes and much less with me.

The simplest modification incorporating this is if the mining pool issues coupon codes for bitcoin to people who mine via TOR instead of sending them actual bitcoin. The pool wouldn't know the name or pseudonym of the coupon recipient. Ultimately, the coupon would be redeemed by a node. However, there is still the issue of limiting access to GPU owners. This seems like a nice way of making a coupon system more anonymous for users with GPUs.

I still think that direct mining provides a slightly higher level of anonymity however. I also like how direct mining would cut out intermediaries in the exchange between user and node. With direct mining, there is no issue with the pool operator disappearing or having downtime etc.

... except the nodes themselves if they start comparing notes.  That's actually something TOR protects against with its multiple-relaying strategy.

i don't understand, your contradicting yourself, compare what ? any node doesn't know what it's in the packets they relay, even if they open a new circuit on behalf of a user connected to them, exactly as you say because tor was built that way, so what can be compared...  :)

Sorry, that was poorly phrased.  Let me give an example:

You connect through BitTOR to Relay-A (exit node).
The Relay-A provides a payment address 1xxxA for access.

Repeat with Relay-B and Relay-C (also exit nodes), addresses 1xxxB and 1xxxC.

You make a transaction with input from your wallet and outputs to 1xxxA, 1xxxB and 1xxxC.

You connect through Relay-A to a web site and post some documents embarrassing a government official.
You connect through Relay-B and post a hypothetical description of how others can find these documents.
You connect through Relay-C to IM and talk with your friends.

If (Relay-A and Relay-C) or (Relay-B and relay-C) provide the government a log of outbound connections associated with a payment address, your identity is compromised.

Normal TOR protects against this.

heh, i was afraid you would say that, please read on how tor works http://en.wikipedia.org/wiki/Tor_(anonymity_network) (http://en.wikipedia.org/wiki/Tor_(anonymity_network))
There's no such thing as connect through node A, B or C, tor doesn't work like a standard anonymity proxy  ;)

I know how TOR works, which is why I was describing A, B, and C as exit nodes.  You connect through a couple other nodes on your way to each one, but the exit nodes can see your raw, unencrypted TCP connections; and you left evidence that you were the same person when you made the payments to those three nodes.

If you still think I'm wrong you'll have to explain it more.

No, you don't have to, i get your point. This going to work only in a straight line (per circuit) so if OP needs a second, or third, exit point that allow IRC, instant messaging or any other port pass they can easily create another circuit altogether. Making the bitcoin payments is easy so you just have to make sure you have at least 1 connection and use "clean" coins.

Oh, I think I see what you're saying.  You're suggesting paying the entry, intermediate, and exit nodes with the same payment?  That's not really necessary.  There are plenty of entry and middle nodes.  Exit nodes are the bottleneck.  Also, making the payment to all three nodes on a circuit with the same transaction has the same problem again - normally the middle node protects you against the entry and exit node collaborating, but the payment would compromise that.

Also, this still has the problem that you need to keep getting clean coins for each new circuit you set up.

Unless I still misunderstand you.  Please explain it more if I do.  :)

Yep, you got me right. I think it's necessary to incentive all the nodes, regardless if they are exit nodes or not. The middle point, or points, that help you defeat collaborating entry and exit OR's would work the same way, they only pass a hash and the node opening the circuit on your behalf doesn't have the ability to see it, just like the hash of the key you share with it.
Regarding that, meh dunno, get a good stash of "clean" coins before you start ?  :D

Just barging in for a moment; been working on exactly this topic every now and then for the last few months.

I think it's possible, but the solution we're developing is very complicated. There are many problems in dealing with attacks on anonymity and attempts to scam the nodes. Very especially the problem is that, unlike in TOR, nodes will be optimized to maximize their own income, not the resulting network performance. This makes the protocol very tedious to design, since the resulting behavior must be proven to be the desired behavior.

Also, TOR itself is more complicated than it seems at first sight. Keeping the data flows anonymous and defending against the various means to censor such a network make every design a compromise. Taget China/Syria/Iran? Better have means to disguise the connection in various ways, and think of means to block probing. Running in northern Europe, not a bridge? It's suddenly all about performance and cheap traffic. And everywhere, there might be a user who wants to be very very certain to remain anonymous. One design that can adapt to all the circumstances would be great, but makes things even more complicated. Charging money adds to the trouble everywhere, think about questions like QoS and the resulting problems with congestion control, or how to behave if a node that has been paid does not deliver.

Extra fun: figuring out which node screwed up when more than one node in the circuit may be controlled by an attacker! Also annoying: if the target of a connection is on the "normal" internet, what happens if the server does not respond or responds with non-signed garbage? The exit node may have simply made up the response and demand payment for routing the "traffic".

Bottom line, I think it's an interesting problem, I want to work on it, however, "it won't be easy" is an understatement. Feel free to message me if you are interested in the project, we may need testers at some point. But don't expect anything to come up soon. Still playing with a variety of designs and probing for crypto problems, hard to tell where this is going.

Also, just a warning to anyone trying the same: don't do this the quick-and-dirty way. It would run great until someone finds an exploit in the dynamics, and then it might go down a lane it can't recover from. Prove that no client can systematically cheat the system to pay it, even if it has access to massive amounts of IP addresses, e.g. is a botnet or government. Similarly, prove that there is no cheap way to DoS the system to death using small amounts of money and again a large amount of IP addresses.

Good luck with that. I hope you succeed.

However, given that

a) you haven't tried to read or respond to what other people have suggested
b) you haven't proposed anything specific that others can respond to.

I don't think success is a probable outcome.

Can you please describe some attack vector? Don't forget that those "redeemable codes" are completely anonymous (if you obtain them with premining over Tor).

Sorry, but it wasn't my intention to layout our design here, but rather hint at the purpose of onion routing and the problems coming with it. Most "quick" proposals are too far off from our idea in terms of how the payments are processed to make me give a simple answer. I've discussed aspects, often on IRC with Bitcoiners, and found multiple threads on here that touch the topic, I'll try to not overlook things. I also talked to Bitcoiners from local meetups, looking for flaws and ideas.

To give a very rough overview, we plan to use a hybrid of Bitcoin and a custom system similar to RipplePay, which is based on yet another that does trust management. Allowing micropayments for traffic priced, but not immediately paid in BTC is one important aspect; distinguishing between trust of anonymity and trust for money another. Automating calculation of the latter type of trust may be the most important aspect, but might also be among the most difficult ones. We want to be truly decentralized.

Time is valuable, so I try to focus on the most relevant discussions. The proposals here are nowhere near matching our desired specification -- being dependent on the profitability of Bitcoin mining is way too risky to have me work on an implementation. Also, decentralization is not sufficient; the system could be disabled by targeting a few manually chosen mining pools. And nobody has explained the crypto that prevents information leaks with horrible dynamics, e.g. the relay knowing which pool which has issued the receipt. This results in a natural monopoly in which the largest pool offers the best anonymity, unless you build a really smart mixing system, which again poses problems not discussed here. And finally, the system is limited to users with hashpower, which is a massive limitation; paying in traffic would promote the pools to banks, adding a lot of manual trust management to the mix. No offense, but this is not the kind of quality we're aiming at, so solutions that would work in such a context are not really relevant for us. For us, this is all-or-nothing: we do it right or we fail trying.

In no way does that mean I'm opposed to any alternative ideas. Just working toward a slightly different goal.

Admittedly, this is just brainstorming, not a serious pursuit. For your part, you are not even seriously brainstorming.
You expect us to believe "my proposal is so good that even the time to give an overview of it is wasted."
Perhaps this is true. Usually, however, people are eager to share their good (but not business-oriented) ideas. The alternative is that your idea is not good and thus you are not eager to share it.

Look, this is going nowhere. Yes, I'm not eager to write down the entire design right now, which is, as you expect, largely unfinished. And no, you can't bully me into doing that just yet. Actually, I'm fine with "is not good and thus I don't want to share it." It's true, in a way, since I just don't have any design documents that have the quality needed for sharing. An incomplete draft would just cause misunderstandings. Give it time. I'll gladly talk about things I believe to understand by now.

IMO, the real hurdle is that the discussion walks largely in unknown territory. The point is to figure out how to deal with anonymity and financial transactions at the same time, facing various types of attacks on both. All systems I know sacrifice one to allow safety in the other, even Bitcoin has no intrinsic anonymity outside of mining. To build a truly better TOR, it may be necessary to overcome this combination. We need a context of thinking that is aware of the dangers from both fields, it is rather about discipline in design than a single idea.

Let's talk about any concrete concept, and I'll contribute if I can. If this continues in a tone like "my psycho skillz show your thoughts are shit", chances are I just stop responding. In fact, I'm already angry at myself at formulating and editing a response to a post that mainly consists of insults.

They're only as anonymous as the issuer makes them.  If the issuer keeps records (court order, or hacked), they become pseudonymous.  TOR tries to prevent single points of failure like this.

Who is "we"?  Is this happening somewhere I can read more about it?

Posts count is good, do you even bother to read before making another post?

Huh?  I didn't (and don't) see the answer anywhere in this thread.  Vandroiy said he doesn't feel like writing it down by which I assume he means he doesn't feel like transcribing a whole other discussion over to here, but he's implied several times that it's a group effort somewhere.

More important for Tor is the ability to have fully implemented network stack for any software, not just TCP connections. I don't care if someone figures out that I run WinXP SP3 like 75% of world does. I need the versatility of VPN with strong anonymity of Tor.

I apologize. I am a very trigger happy in cursing people out and some of the targets do not deserve it. You say you want to combine bitcoin and something like ripple pay. It sounds like something which would have broader functionality. Can you provide more details? i.e. a simplified step by step outline of how this might work. It is often better to start discussing that than a fully specified design. I promise not to go into asshole mode again on you.

Incorrect. Those premined codes are anonymous, because every share submit can be isolated, so there's no identity link between more "codes". There's simply no "keeping records" possible.

This is true only if you create a new TOR tunnel after you receive each code.  It's possible, but it would be quite inefficient.

It is necessary only after share submit, not for every getwork request. Also nobody said that "one code" == "difficulty 1 share", it can be little higher to prevent system overhead.

I agree, which is why I said it has to change per code, not per share.

The codes have to be relatively small amounts of value so that you don't lose much whenever you abandon one relay and set up a new tunnel (in case they're not performing well, or you need a new identity), so there are practical limits to the number of shares per code.

On the other side, tracking many small-value codes would be a large bookkeeping operation.

All told I think it's potentially workable, just potentially inefficient.

I just realized why this idea could have another very huge but subtle implication rather than just letting people browse anonymously. It would provide a very easy way to get your hands on bitcoins that could out-compete even mining.

Mining is currently the number one way to get bitcoins. The problem is that it requires specialized hardware, and thus shuts most people out. If it were somehow as easy to earn bitcoins with your bandwith as with your GPU, we could see a new craze even bigger than the last rally, with posts on all different forums telling you on how to set up a TOR/i2p node to earn bitcoins. Just think about all the people who currently use their spare bandwith for seeding torrents. That's a lot of people that would be inclined to take a closer look on bitcoin. The P2P community as well should embrace such a step even if it would compete with seeding, since it could make truly anonymous file sharing possible.

I believe something like this could be a very important step to lose the reliance on exchanges. Not many people know a bitcoin miner. Far more people know a pirate or can at least get in contact with a pirate fairly easy, and would thus have a way to get bitcoins in a decentralized manner.