[ANNOUNCE] Bitcoin Fog: Secure Bitcoin Anonymization

[Atheros]

Everybody,
I wouldn't worry about bloating the blockchain. These transactions can be pruned from the blockchain once Bitcoin clients support pruning.

This would work, but I worry a little about users who do not read all instructions properly/forgot instructions/similar that made two deposits to the same address. If we are going to change the deposit address automatically, every deposit after the first one, to each of addresses will be lost, because there are going to be a LOT of these addresses and we are not going to be able to keep track of all of them. Do you think that all users will be able to only keep it at max 1 transaction per address?
Maybe we could at least start by changing the text on the deposit page that it is HIGHLY RECOMMENDED to change the address after each deposit.

Perhaps a button to delete old addresses? A verification prompt will say "Are you sure you want to delete all of your old addresses? You must be sure to not send any money to these addresses from now on. Use only new addresses."

[casascius]

The most secure way to anonymize funds I can think of, would be to offer a service that attempts to aggregate the funds being anonymized into one HUGE transaction, and then splits the outputs into brand new addresses, the outputs being in standardized increments (like 1,5,10,20... or 1,2,4,8,16,32,etc.).

Such a service could be implemented in a way that keeps customers immune from theft by never requiring them to send their bitcoins into the service.  Rather, the service would release an open-source client that would read the wallet.dat, submit the bitcoin addresses to the service, along with a bunch of fresh addresses in a new wallet.dat, and the service would simply propose the huge transaction (in other words, create the transaction, missing the digital signatures needed for bitcoin to accept it).  The clients would provide the necessary digital signatures for the huge transaction immediately once they confirmed that the huge transaction was honest, at least with respect to the funds being anonymized by that particular user.

To keep the transaction as huge as possible, the anonymization would be done infrequently, such as weekly.  A hypothetical huge transaction could have 500 inputs totalling 200,000 BTC, broken into 1,000 outputs.  From the view of the block chain, it is clear the funds have been anonymized as they will all clearly be combined into a giant transaction, but the trail goes stone cold from there.  Any output could plausibly be from any of the inputs.

One disadvantage is that it could be DoS-attacked: the huge transaction would need 100% participation from all clients submitting funds.  If even one client failed to sign, a new transaction would have to be generated without that client's funds (i'll call it a "recycle").  An attack consisting of a large number of sockpuppet clients, each of which forced one recycle to take place, could make such a system difficult to use.

The only point of failure would be the person running the service, they could be a honeypot and recording whose outputs are whose inputs.  Otherwise, if the person running it wasn't doing this, and the huge transaction was sufficiently huge, it would be pretty airtight I would think...

[theymos]

More suggestions:

It should be possible to schedule a withdrawal even if the balance is 0. Once the balance is above 0 and properly confirmed, the BTC will be sent. Then I don't have to visit the site twice to do mixing.

I just received my two withdrawal transactions only 3 blocks apart, which seems too short.

It's good that you're not always sending with full precision, but it would be better to choose the amount of precision based on probabilities observed in the block chain. Looking at the last 10,000 blocks or so, the probability of an output having a certain number of decimals after the decimal point was:
- One decimal: 5%
- Two decimals: 21%
- Three decimals: 6%
- Four decimals: 8%
- Five decimals: 1%
- Six decimals: 1%
- Seven decimals: 5%
- Eight decimals: 47%

Do you think that all users will be able to only keep it at max 1 transaction per address?
Maybe we could at least start by changing the text on the deposit page that it is HIGHLY RECOMMENDED to change the address after each deposit.

Maybe use the current method by default, but have an option that enables the more anonymous method.

[Akemashite Omedetou]

Perhaps a button to delete old addresses? A verification prompt will say "Are you sure you want to delete all of your old addresses? You must be sure to not send any money to these addresses from now on. Use only new addresses."

Yep, that's pretty much how it works today.

casascius, your idea sounds interesting. I don't know about implementing the whole thing you have described, but the idea of having only one payout/transaction every week, and combine all deposits and payouts in it is definitely worth something. It eliminates all sorts of timing analysis, as long as there are enough users every week.

It's good that you're not always sending with full precision, but it would be better to choose the amount of precision based on probabilities observed in the block chain. Looking at the last 10,000 blocks or so, the probability of an output having a certain number of decimals after the decimal point was:
- One decimal: 5%
- Two decimals: 21%
- Three decimals: 6%
- Four decimals: 8%
- Five decimals: 1%
- Six decimals: 1%
- Seven decimals: 5%
- Eight decimals: 47%

Right now the precision of each payout is randomized as well. If course, if there are only 2 or 3 payouts (which there are if amounts are small, due to tx fees), then most of them will always have the same precision, because the sum of them must still add up to the amount the user wants to withdraw.
It would be interesting to implement the distribution you have provided instead of blind randomizing. However, I don't see that it does much for anonymization, since the fact that the money came from our service will be visible anyways (as of now, all payouts are mostly done from the same address), and analysis of precision does not do much for identifying the deposit associated with this withdrawal, since they all are randomized. Or am I missing something?

[casascius]

casascius, your idea sounds interesting. I don't know about implementing the whole thing you have described, but the idea of having only one payout/transaction every week, and combine all deposits and payouts in it is definitely worth something. It eliminates all sorts of timing analysis, as long as there are enough users every week.

Do some research on the "sendmany" RPC command.

[Akemashite Omedetou]

Seemed important enough to make this public, I have two announcements:

1). We have been updating our payout engine to not make use of the offical bitcoin client-accounts system, which now after a time of real world operation seems unreliable. From now on we will only rely on our own accounting. We did not actually use bitcoind-accounts for real balance checks, but transactions were based on that. Long story short, as a result, some payouts today and tomorrow may become a couple of hours late due to the payment system upgrading (and thus downtime).
All balances and wallets are in check of course, just small delays on payouts.

2). Some users have been requesting payouts to invalid addresses.
Our service does of course check the address for looking valid, but not every string containing the right number of characters from the right character set and starting with "1" is a valid bitcoin address. These particular addresses were denied by the bitcoin client, and no payments were done. We have now manually reinserted the lost money into the system and routed it to the proper accounts, so your balance should be available for new payouts, but please note that we will not be checking for improper addresses in the future. It is your responsibility to provide us with proper addresses.
If you feel this is somehow our fault still, please contact us here or using the soon-to-be-done contact form in the tor service itself.

[Etlase2]

2). Some users have been requesting payouts to invalid addresses.
Our service does of course check the address for looking valid, but not every string containing the right number of characters from the right character set and starting with "1" is a valid bitcoin address. These particular addresses were denied by the bitcoin client, and no payments were done. We have now manually reinserted the lost money into the system and routed it to the proper accounts, so your balance should be available for new payouts, but please note that we will not be checking for improper addresses in the future. It is your responsibility to provide us with proper addresses.
If you feel this is somehow our fault still, please contact us here or using the soon-to-be-done contact form in the tor service itself.

The last 4 or 5 bytes of every bitcoin address is a checksum, you should be able to check that an address is valid the same way that the client does. Anything less would mean you're lazy.

[Akemashite Omedetou]

The last 4 or 5 bytes of every bitcoin address is a checksum, you should be able to check that an address is valid the same way that the client does. Anything less would mean you're lazy.

Fair enough, this goes into the TODO-pile.

[theymos]

Here's PHP code I wrote to do address verification (and other things):
http://pastebin.com/vmRQC7ha

Bitcoin also has a validateaddress JSON command.

[casascius]

2). Some users have been requesting payouts to invalid addresses.
Our service does of course check the address for looking valid, but not every string containing the right number of characters from the right character set and starting with "1" is a valid bitcoin address. These particular addresses were denied by the bitcoin client, and no payments were done. We have now manually reinserted the lost money into the system and routed it to the proper accounts, so your balance should be available for new payouts, but please note that we will not be checking for improper addresses in the future. It is your responsibility to provide us with proper addresses.
If you feel this is somehow our fault still, please contact us here or using the soon-to-be-done contact form in the tor service itself.

The last 4 or 5 bytes of every bitcoin address is a checksum, you should be able to check that an address is valid the same way that the client does. Anything less would mean you're lazy.

Fair enough, this goes into the TODO-pile.

No... that puts this whole project in the FAIL pile in my view.  Sorry.

You really need to take the job more seriously if you're going to handle other people's money.  What no one wants to hear is, "oops, I just sent some/all of the BTC to the wrong person" (or "the wallet.dat with your bitcoins got corrupted" etc.) "and can't afford to replace it.  Sorry, I never knew that was even possible"...

Unfortunately, this screams of technical non-familiarity with Bitcoin - which is fine - everyone has to start somewhere.

But I don't think that someone who just barely learned that bitcoin addresses have checksums, for example, is qualified to run a bitcoin anonymity service.  Even MtGox screws up from time to time, and they're definitely not newbies.  Consider trying something else for your first bitcoin endeavor, let this one be your second or third.

[tvbcof]

...
Unfortunately, this screams of technical non-familiarity with Bitcoin - which is fine - everyone has to start somewhere.
...

The up-side is that it also screams "I'm not running a sophisticated honeypot on behalf of well capitalized players."

[Akemashite Omedetou]

You really need to take the job more seriously if you're going to handle other people's money.  What no one wants to hear is, "oops, I just sent some/all of the BTC to the wrong person" (or "the wallet.dat with your bitcoins got corrupted" etc.) "and can't afford to replace it.  Sorry, I never knew that was even possible"...

Well, I think you misinterpreted events a little bit, since they are really far from "oops, I just sent some/all of the BTC to the wrong person". Actually not even "Sorry, I never knew that was even possible".
We did know this was possible, the only checks on addresses we did were for the proper number of characters and proper set of characters, because we assumed that well, if you are going to let us handle your money, you will at least make sure to enter right addresses for the payouts.
Unless the users contact us and we will discover that our service somehow tried to pay to a wrong address even though the user did enter the right one. We have checked both logs and the code looking for such possibility, but have not found anything. Having said that, no software in the world is bug-free and everything is possible, so if that will be shown to be the case, we apologize.

However, as of now no money has been lost, nor were any money of other users ever in any danger because of this, the service is operational as usual, we even redeemed the balances of users that did this. You think that we should have done something differently?

Like I said, we will implement the checksum check, but that is not really on top of the priority list, since it is just a small usability thing, with no security implications.

Here's PHP code I wrote to do address verification (and other things):
http://pastebin.com/vmRQC7ha

Bitcoin also has a validateaddress JSON command.

Great! For security reasons the front-end of our solution cannot call bitcoind directly, but the offline version based on your code should work fine.
On a different topic, theymos, you seem to know enough about bitcoin to be Satoshi Even saw your signature in blockexplorer errors, great job there!

[FreeMoney]

Right now the precision of each payout is randomized as well. If course, if there are only 2 or 3 payouts (which there are if amounts are small, due to tx fees), then most of them will always have the same precision, because the sum of them must still add up to the amount the user wants to withdraw.

Charge a random fee? Something between 1.5% and 2.5%? Even 1.95-2.05 would probably help.

It would be interesting to implement the distribution you have provided instead of blind randomizing. However, I don't see that it does much for anonymization, since the fact that the money came from our service will be visible anyways (as of now, all payouts are mostly done from the same address), and analysis of precision does not do much for identifying the deposit associated with this withdrawal, since they all are randomized. Or am I missing something?

Why would you do this? You move all funds to one address?

Of course that helps identify where the money comes from. Now you know it comes from some of your 1, 10, 100 customers. You'll never have so much traffic that that fact is useless.

Are you doing this because you are paying your own coins until you build up a new large stash of deposited coins? Like seed money that happened to be in one address? Seems you could have mixed that up some itself.

[casascius]

However, as of now no money has been lost, nor were any money of other users ever in any danger because of this, the service is operational as usual, we even redeemed the balances of users that did this. You think that we should have done something differently?

Of course no money has been lost.  But the probability of mistakes, however low, is always there.  If a big mistake happens, an apology won't cut it.  Saying you can't afford to replace all of the lost bitcoins won't cut it.  Those of us who used your service will properly feel stupid for having done so, and we'll have yet another security scandal to hit the media.  Even MtGox has lost bitcoins.

If there's something you can do differently, one example might be to publish the "sendmany" transaction you plan to emit, a certain amount of time in advance, so people can verify for you that it's correct.  By publishing the transaction, I mean in JSON format as you would pass it to the RPC (containing only bitcoin addresses and amounts), not a signed transaction that will go in the block chain.

Another thing you can do is tell us how you manage your private keys that receive the incoming funds.  If you told us, "these keys are generated on an offline computer and the private keys never touch the internet", this paints a much better picture than the assumption that, for example, the security of the entire operation is hinged on nobody breaking into your machine which is online 24/7 and has its own public IP and has a half dozen ports open.

The ultimate solution would be a client-server anonymizer where the client always controls the funds until the server broadcasts a satisfactory mass transaction that all the clients agree is safe, and then the client software does all the signing.  This would be bulletproof and would present virtually no risk of loss or theft to any of the clients.

[Akemashite Omedetou]

UPD: ahh, you removed the post just before I could write up an answer 
Are you just revising it or should I remove all the references to it?

FreeMoney,

Charge a random fee? Something between 1.5% and 2.5%? Even 1.95-2.05 would probably help.

This is certainly something to consider!

casascius

Of course no money has been lost.  But the probability of mistakes, however low, is always there.  If a big mistake happens, an apology won't cut it.  Saying you can't afford to replace all of the lost bitcoins won't cut it.  Those of us who used your service will properly feel stupid for having done so, and we'll have yet another security scandal to hit the media.  Even MtGox has lost bitcoins.

That is an unfortunate scenario you are describing, and of course it is possible. It is also *possible* that a lightning strikes our servers and all the backup locations, which will be unfortunate as well. But to this point we have been going into this with the intention to make the risks as low as possible, and we have outlined both here and on bitcoinfog.com which steps we have taken.

If there's something you can do differently, one example might be to publish the "sendmany" transaction you plan to emit, a certain amount of time in advance, so people can verify for you that it's correct.  By publishing the transaction, I mean in JSON format as you would pass it to the RPC (containing only bitcoin addresses and amounts), not a signed transaction that will go in the block chain.

So we should make it easier for an attacker/analyzer to do statistical analysis on our payouts even before they are made and helping them to start finding our bitcoin client? (that could only be done by an authority of course, because that would mean having control over a LOT of nodes, but still)

No, we won't make their life easier, this most probably WILL NOT be implemented.

And how would people verify that the tx is correct? Just checking all the addresses? Don't you think that it is easier for people to just check the addresses when they are putting them into the withdraw form of our service?

Another thing you can do is tell us how you manage your private keys that receive the incoming funds.  If you told us, "these keys are generated on an offline computer and the private keys never touch the internet", this paints a much better picture than the assumption that, for example, ...

The bitcoind service is run on a different machine than the front-end. They communicate by the means of a database. The database engine is not run on the same machine as the front-end either.
The front-end does not have access to the private keys.

I might be able to answer more specific questions, but I will not reveal much more about our exact configuration, because while it might be reassuring to you, it could also aid a hypothetical attacker. And any attacker in the world would just love the owner of a server to describe how it is built and setup

the security of the entire operation is hinged on nobody breaking into your machine which is online 24/7 and has its own public IP and has a half dozen ports open.

It does NOT actually have a public IP, this is the reason we are running it through TOR.

For more information about TOR hidden services please read up on their website.

Now, even if the bitcoin fog service would run through tor, we *could* still be running other publically available services on that machine or even put the whole thing on a shared hosting, if we were douche-bags, but luckily, we are not :-).

Both servers are running secure OSes with proper settings, are updated regularily and are behind a NAT. We also did manual port scans on them (even from within the NAT) to check the security.

Creating a service to anonymize other people's bitcoins requires a highly advanced familiarity, nearly on par with the developers.  I used the checksum as an example of a red flag, because if you're unfamiliar with the checksum, you're unfamiliar with the project's source code.  Have you heard of the scripting system?

I am sorry but you have clearly misinterpreted some things again. Where did I state that I was unfamiliar with the checksum mechanism? I only said that checking for it was not a priortity, because ask us, users should be able to provide us with proper addresses if their money is important to them. It is not like copy-pasting a string of characters is challenging nor should be something new to anyone dealing with bitcoins.

Randomizing payouts does nothing useful by itself.  If there are 60 payouts, and I want to know which two or three of the 60 payouts come to a total of, say, 3.32075 BTC, and you're allowing outputs to 8 decimal places... and looking at the 60 figures I see there are only 3 of them that could possibly add up to that total, then it's fairly obvious how they correlate.  When you're dealing with numbers with up to 8 decimals, it's actually likely that you can guess which numbers belong to which output, because few or no other possible combinations of the remaining numbers could possibly produce the same sum.  Undoing your anonymization would be like solving a Sunday newspaper sudoku puzzle - with a computer doing all the work.

You should really read up more on our website or the first post of this topis. This is described in quite a detail there.

It is a no-brainer that no matter which transactions, if the total adds up to the same value, statistical analysis will be possible.

However, we cannot force our users to withdraw smaller amounts than they have deposited and keep more money on our service. We do recommend this however, and exact mechanism of this, once again, is decribed in the first post.

Randomizing the fee is a great idea and we will implement it, but there are two problems: if the spread is too big, it is unfair to  users. If it is too small, the effect of it is also small, and any good statistical analyser will see through these tiny manipulations if no caution is taken. Still, this will at least help against users blindly withdrawing the EXACT amount they have put in.

You also seem to have the idea that we use full precision for payouts right now or that we use same precision for each payout wihhin the same withdrawal. This is not the case. Also note that we payout to different addresses if users have provided us with multiple ones.

Also, do note that (and I believe we haven't really ever talked about this one) ALL payouts are approximately of the same order of magnitude. That is, if you withdraw 10 BTC, and someone else will withdraw 100 BTC, your payouts will not be 10 times smaller, there will just be fewer of them. Otherwise you could just easily check the approximate size of payouts to guess to whom they belong pretty easily

Compare to strictly using "powers of two" to do payouts.  3.32075 might be paid out as 2 + 1 + 0.25 and the remaining 0.07075 would be forfeited as a fee.  When combined with lots of other outputs that are all broken apart exactly the same way, these denominations would provide no useful information.

As for forfeiting a random value, this will be implemented as a part of “random fee” feature.

As for using the powers of 2, I will check with our mathematician, but what exactly does make this
0.25 -> 1sWmdS
0.25 -> 1aasdF
0.25 -> 1aasdF
0.25 -> 1sWmdS
0.25 -> 1aasdF
0.25 -> 1aasdF
0.5 -> 1sWmdS

harder to analyze than
0.23 -> 1sWmdS
0.36902062 -> 1aasdF
0.18097938 -> 1aasdF
0.46274 -> 1sWmdS
0.2 -> 1aasdF
0.025 -> 1aasdF
0.30726 -> 1sWmdS

?

Both are pretty easy to analyze, that is why we always suggest to our users to never withdraw the same amount that they have put in...

This would be another place that would lead me to doubt that this is being run competently.  Sorry for the criticism.  I want your service to exist, but I don't want it to be run by someone who is just barely figuring out how to make it work.  I really hate to be ripping on someone who seems to be trying to provide something useful that there is clearly a demand for, but this kind of operation requires a great deal of familiarity with the source code and the data structures involved, along with a security-conscious mind that intuitively can understand what kinds of attacks would be made against a service like this.

Well so far I cannot say that you have really showed any real flaw of our system, and your critic was mostly based on you not fully understand how we operate. So we fully support this and it is always good to see this kind of criticism, because the more we explain how we work, the more we believe that users will see our service for what it is and use it.

I am sorry that you have received this apparent general feel that we are a bunch of 16yearolds that just learned some BASIC, but as an anonymous service we will just have to answer all your question in the biggest detail possible and take the time to prove you wrong

[mndrix]

It is not like copy-pasting a string of characters is challenging nor should be something new to anyone dealing with bitcoins

I suspect that many users who want anonymous Bitcoins aren't copy-pasting; they're using paper wallets and typing the addresses in manually.  That way, the funds sent to each address can never be connected via other transactions from the same wallet.

[casascius]

That is an unfortunate scenario you are describing, and of course it is possible. It is also *possible* that a lightning strikes our servers and all the backup locations, which will be unfortunate as well. But to this point we have been going into this with the intention to make the risks as low as possible, and we have outlined both here and on bitcoinfog.com which steps we have taken.

Good backups can't be assumed unless you explicitly take credit for them.  But really, the more likely scenario I am thinking of, is like the recent one with Intersango, where someone's withdrawal was paid 512 times to someone who felt entitled to keep the overpayment, to MtGox, who recently sent bitcoins to never never land.

So we should make it easier for an attacker/analyzer to do statistical analysis on our payouts even before they are made and helping them to start finding our bitcoin client? (that could only be done by an authority of course, because that would mean having control over a LOT of nodes, but still)

No, we won't make their life easier, this most probably WILL NOT be implemented.

This is further evidence of not understanding how Bitcoin works.  Your very same payout transaction will be seen in the block chain, so you aren't gaining anything by refusing to provide your proposed transaction in advance.  Statistical analysis should yield nothing unless you're using a poor method to randomize your transaction outputs.  And it is between very difficult to impossible to tell whether an incoming transaction originated from the connected node, versus being simply relayed by that node.  You're using Tor as you note before, so your apparent IP shouldn't even matter.

And how would people verify that the tx is correct? Just checking all the addresses? Don't you think that it is easier for people to just check the addresses when they are putting them into the withdraw form of our service?

They would be able to verify that you intend to send a total of BTC spread across their addresses, consistent with their expectations.  They might be able to alert you if there is any bug/problem before the BTC transaction actually gets committed to the block chain.

It does NOT actually have a public IP, this is the reason we are running it through TOR.

Excellent. +1

I am sorry but you have clearly misinterpreted some things again. Where did I state that I was unfamiliar with the checksum mechanism? I only said that checking for it was not a priortity, because ask us, users should be able to provide us with proper addresses if their money is important to them. It is not like copy-pasting a string of characters is challenging nor should be something new to anyone dealing with bitcoins.

The fact that you felt it unnecessary to implement - or didn't know to implement this - leads me to the same conclusion.  The checksum is there for a reason.  The idea that users should make perfect inputs on the basis that their money is "important" is a nice theory.  Having your service simply not pay, rather than tell them to check their input and try again, is ... something I shouldn't feel I have to explain.  You should know better.

As for using the powers of 2, I will check with our mathematician, but what exactly does make this
0.25 -> 1sWmdS
0.25 -> 1aasdF
0.25 -> 1aasdF
0.25 -> 1sWmdS
0.25 -> 1aasdF
0.25 -> 1aasdF
0.5 -> 1sWmdS

harder to analyze than
0.23 -> 1sWmdS
0.36902062 -> 1aasdF
0.18097938 -> 1aasdF
0.46274 -> 1sWmdS
0.2 -> 1aasdF
0.025 -> 1aasdF
0.30726 -> 1sWmdS

?

Both are pretty easy to analyze, that is why we always suggest to our users to never withdraw the same amount that they have put in...

Both are pretty easy to analyze, because you have unnecessarily chosen to use the same addresses repeatedly ("1aasdF" and "1sWmdS") to pay the same two people.  This isn't even anonymizing, this is more like bloating the block chain.  Consider having each person provide you a large number of addresses, and use each one only once.  Then ask the same statistical analysis question again with each 0.25 going to a unique address.

Well so far I cannot say that you have really showed any real flaw of our system, and your critic was mostly based on you not fully understand how we operate. So we fully support this and it is always good to see this kind of criticism, because the more we explain how we work, the more we believe that users will see our service for what it is and use it.

I am sorry that you have received this apparent general feel that we are a bunch of 16yearolds that just learned some BASIC, but as an anonymous service we will just have to answer all your question in the biggest detail possible and take the time to prove you wrong

I wish you luck.  I can't recommend your service, but I shall not fault you for looking to provide something useful to the Bitcoin community.  I just wish that (in my view, which I think is pretty solid) it didn't have to burden people with risk that you don't seem to appreciate.  Lots of people much older than 16 are not well suited to provide this service, I don't think you're acting like a teenager, just more that you're biting off more than I think you can chew (and others, not you, take any fall).  Best of luck though.  And I am certain that you will quickly progress to the point where these criticisms of mine will be moot, because I've essentially said you are insufficiently experienced with the innards of the Bitcoin system, surely that will change.

[Akemashite Omedetou]

I suspect that many users who want anonymous Bitcoins aren't copy-pasting; they're using paper wallets and typing the addresses in manually.  That way, the funds sent to each address can never be connected via other transactions from the same wallet.

There are surely users like that indeed. (I mean, we did see the evidence of this a couple of days ago ) The checksum is definitely going in there.

This is further evidence of not understanding how Bitcoin works.  Your very same payout transaction will be seen in the block chain, so you aren't gaining anything by refusing to provide your proposed transaction in advance.  Statistical analysis should yield nothing unless you're using a poor method to randomize your transaction outputs.

This is further evidence of you not thinking this fully through.
What you are proposing is publicly announcing all payments a week before they are actually made. In that week new users will add funds to the Fog and some of them may request new payouts. But when the transaction is sent to the network, any attacker can be sure of the fact that whoever are recipients of bitcoins from it requested the payout 1 week before which will just narrow their search area, which would otherwise include the new users from this week, some of which might have also requested a payout in that week. Besides, making users to wait for a week or even a couple of days to get a payout does not seem very user friendly.

Saying that we don't understand that the transaction will be seen in the block chain again gets me thinking you still did not read the first post here or the introduction on bitcoinfog.com, please do that.

They would be able to verify that you intend to send a total of BTC spread across their addresses, consistent with their expectations.  They might be able to alert you if there is any bug/problem before the BTC transaction actually gets committed to the block chain.

The idea that users should make perfect inputs on the basis that their money is "important" is a nice theory.  Having your service simply not pay, rather than tell them to check their input and try again, is ... something I shouldn't feel I have to explain.  You should know better.

So the users are not perfect enough to input right addresses from the start, but they will be perfect enough to go and check a big list of transactions, find their addresses, calculate the exact amount from their transactions spread over that big list and report this back to us?

No, the real solution here is to just implement the checksum eh... check.

The fact that you felt it unnecessary to implement - or didn't know to implement this - leads me to the same conclusion.  The checksum is there for a reason.

Once again, a question of priorities. We felt it is necessary to implement a secure and anonymous service that will work operate, which we did. The rest was prioritized down. Like I said, we will get it there eventually.
As for your conclusion - you seem to come to the same conclusion no matter what the inputs are

Both are pretty easy to analyze, because you have unnecessarily chosen to use the same addresses repeatedly ("1aasdF" and "1sWmdS") to pay the same two people.  This isn't even anonymizing, this is more like bloating the block chain.  Consider having each person provide you a large number of addresses, and use each one only once.  Then ask the same statistical analysis question again with each 0.25 going to a unique address.

Practically that will never be the case, because I don't think all the users need that much anonymity that they will go to the trouble of creating a lot of addresses every time they need a payout. If they do, however, it is possible already to spread all the transactions between many addresses.

But let's say that this was the case. We have 10transactions that go 10 different addresses. What exactly makes it easier to analyze a list of random, never repeating numbers that go to different addresses than a list of 0.25 and 0.5 that go different addresses? Keeping in mind that let's say we have fixed the same input/output amount by randomizing fees.

I just wish that (in my view, which I think is pretty solid) it didn't have to burden people with risk that you don't seem to appreciate.  Lots of people much older than 16 are not well suited to provide this service, I don't think you're acting like a teenager, just more that you're biting off more than I think you can chew (and others, not you, take any fall).  Best of luck though.  And I am certain that you will quickly progress to the point where these criticisms of mine will be moot, because I've essentially said you are insufficiently experienced with the innards of the Bitcoin system, surely that will change.

Well since we will try to stay anonymous at all costs, we can't really provide you with our portfolio or similar, so it will unfortunately have to stay the issue of trust, but you are welcome to present any evidence that we might be under-qualified to run such a service.

[casascius]

Both are pretty easy to analyze, because you have unnecessarily chosen to use the same addresses repeatedly ("1aasdF" and "1sWmdS") to pay the same two people.  This isn't even anonymizing, this is more like bloating the block chain.  Consider having each person provide you a large number of addresses, and use each one only once.  Then ask the same statistical analysis question again with each 0.25 going to a unique address.

Practically that will never be the case, because I don't think all the users need that much anonymity that they will go to the trouble of creating a lot of addresses every time they need a payout. If they do, however, it is possible already to spread all the transactions between many addresses.

What do you mean?  That's the only way such a thing could work.

If all you are doing is breaking their transaction into three pieces and sending them back to one of their own addresses, they can do this themselves without your service.  They could just do a "sendmany" and write one of their own addresses three different times.  It would be just as un-anonymous.

But let's say that this was the case. We have 10transactions that go 10 different addresses. What exactly makes it easier to analyze a list of random, never repeating numbers that go to different addresses than a list of 0.25 and 0.5 that go different addresses? Keeping in mind that let's say we have fixed the same input/output amount by randomizing fees.

Because if you know the total of one of the anonymized inputs, you can deduce which outputs belong to it, simply by adding all of the outputs together and looking for a combination that adds up to the input..

Example: I have an input of 107.325.  Which outputs match?   27.4  1.325  100  6  73.212  57  28.592834 16.3072  1045

The only three possible numbers that could have added to 107.325 are 100+6+1.325..

Now, I have an input of 107.325.  Which outputs?  256 128 64 64 64 32 16 16 8 8 8 8 4 4 2 2 2 1 1 1 0.5 0.5 0.5 0.25 0.25 0.25 0.125 0.125 (and assume amounts below 0.125 can be swallowed as fees)

See the difference?

[adamstgBit]

if you've used this service consider writing a review for it @ http://www.thebitcoinreview.com/site.php?site_id=759

Help Build trust