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.
Topic: Tor Idea. (Read 8776 times)
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.
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.
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.
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.
They're only as anonymous as the issuer makes them. If the issuer keeps records (court order, or hacked), they become pseudonymous.
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.
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.
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.
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.
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.
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.
the solution we're developing
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?
the solution we're developing
Who is "we"? Is this happening somewhere I can read more about it?
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).
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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 ?
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.
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.
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.
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.
Jump to: