Tor Idea.

[runeks]

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.

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?

[Revalin]

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

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.

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

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

[runeks]

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

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.

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

[cunicula]

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.

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

[Revalin]

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.

[cunicula]

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.

[Revalin]

If authorities can arrest and prosecute anyone without proof, why don't they just do that to Tor users?

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.

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

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

[Revalin]

The low end GPU you cite is quite low-end, and even that yields maybe 80 kb/s in your calculation.

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. 

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

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.

[Serith]

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.

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.

[paraipan]

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

A user’s OP constructs circuits incrementally, negotiating a
symmetric key with each OR on the circuit, one hop at a time.
To begin creating a new circuit, the OP (call her Alice) sends
a create cell to the first node in her chosen path (call him
Bob). (She chooses a new circID CAB not currently used on
the connection from her to Bob.) The create cell’s payload
contains the first half of the Diffie-Hellman handshake (g x ),
encrypted to the onion key of the OR (call him Bob). Bob
responds with a created cell containing g y along with a hash
of the negotiated key K = g xy .

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 ?

[Revalin]

She can make a payment too all of them with only one transaction

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.

[paraipan]

She can make a payment too all of them with only one transaction

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.

[2_Thumbs_Up]

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.

[cunicula]

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.

[Revalin]

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.

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

[paraipan]

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.

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

[Revalin]

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.

[paraipan]

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)
There's no such thing as connect through node A, B or C, tor doesn't work like a standard anonymity proxy  

[Revalin]

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.

[paraipan]

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.