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
