Quote from: BTCGameMaker on September 13, 2011, 05:37:44 AM

This post doesn't seem to be getting a lot of attention, which is interesting considering anonymity is one of the best features of Bitcoin. Part of the problem might be that you're explanations seem kind of technical and are hard to follow. That being said, I've been thinking along the same lines as this for a while. This is the working theory that I've come up with.

1. You have user clients and an ASR as you said.
2. All transactions between the clients and the ASR will be for 5 BTC.
3. If a user wants to send 6 BTC to a third party. They will send 5 BTC to two separate addresses controlled by the ASR. From any other addresses the ASR will send a total of 6 BTC to the third party. The ASR will then log the balance of 4 BTC under a unique address.
4. If a user wants to receive 6 BTC from a third party the ASR generates a unique address for the user. After receiving the 6 BTC, the ASR sends 5 BTC to the user and records the balance of 1 BTC under a unique address.
5. The user can as necessary draw from the balance to cover transactions less than 5 BTC or withdraw 5 BTC at a time if the balance exceeds this amount. In this way the ASR will have control over a maximum of less than 5 BTC for any given user.

With enough traffic this should significantly conceal the connections of any transactions entering or leaving the ASR.

Other safety measures I've considered.

1. Have the ASR broken into programs split across multiple servers, so that hacking one server will not allow for control of the entire system.
2. Require that all transactions be confirmed by multiple servers independently.
3. Have all database entries double encrypted with one key being held on the server and one key being held by the user client. In this way no database entries would be readable without the client that created them.
4. Have all programs making of the ASR sufficiently obfuscated and rewritten on a regular basis. In this manner, even if someone hacked the server and gained access to the software, by the time they deciphered the software new software would be in place.

I've been playing around with how to implement this already, but it's kind of a big undertaking. The user client would have to control all the tracking of funds behind the scenes so that it is easy for the user and the least amount of information possible is available to the ASR. Then you would also need to create the ASR broken into multiple parts, and create an obfuscation program that could randomly replace variables and insert code to properly disguise the functioning of the program.

I agree with you that this is an issue that needs to be addressed and that current systems don't work. But based on the attention this thread has gotten so far, I'm not sure the community actually takes this that seriously.

Thanks for your comments. It seems like you can either restrict in the inputs (as you propose above) or the outputs (as I proposed), to the same effect. There are advantages to each. One downside to maintaining a balance on the server is that it's a form of state to maintain, whereas the ASR I described above would not maintain any state except temporarily.

Unless some big exchange or other service starts using the ASR, it'll be really hard to get traction.