Thanks for all the inputs, I'll try to answer all.
Your whole attitude to something that is this trivial to implement, but has such important consequences for your users, is astounding. I can understand why casascius reached the conclusion that you either don't know much about bitcoin. This doesn't need to be added to a to-do list. This doesn't need to be prioritized above or below something else. This is an integral part of the core address handling system. Not having this in the first place decreases my confidence in you as developers greatly. (Take this how you want it. This is not an insult per se, but just an example of how people might look at your service when they first encounter it.)
Sure, however I already said it will be included in the near future.
And the argument "you can do it in 5 mintues" is not really the case. It does take 5 minutes to implement, but both you and me understand that such a service as ours does need to do everything perfectly, so every new thing must be tested, and tested thoroughly. And that does not take 5 minutes.
Why was this not implemented from the beginning?
Because the only consequence is that the user has to input an address again. It is not critical nor game changing. No money can ever be lost or sent to a wrong account because of this. (You know that the bitcoin client we use does check the checksum, right?
So no actual faulty transactions are ever sent to the network by us? The only "strange behaviour" would be in the scheduler and as I explained before, we have reversed any small effects that it does, and will do so until we implement the check?)
Come to think of it, did you guys think that some money was actually lost because of this? Maybe I wasn't clear enough...
In any case, I'm glad we've been able to convince you of the importance of the checksum. Eventually.
That was the main thing that bugged me.
Of course it is important and will be included. I was with you on this one from the first mention of it, wasn't I?
as of now, all payouts are mostly done from the same address
That seems strange, for an anonymizing service, but you plan on fixing that, so it should be okay.
That is not actually the case anymore, but does it really add much more security? As Etlase2 have pointed out, those addresses would be trivial to find.
We are working on some schemes to really have A LOT of addresses and make it look like we are inputting and outputting funds out of the system and back in, when in reality those will be just obfuscation transactions between our own addresses. The problem with that is how make our addresses really look like they are external. There are some ways, but none we know of are bulletproof.
We welcome any ideas here.
Uhm, I'm afraid to ask this… You took into account that addresses can also have less than 34 characters, right? As in, anywhere from 25 to 35?
No way! REALLY? More, we just found out, an address must start with "1"! This is really a shocker!
Sorry, got carried away here
. But yeah, we knew. Like I said, the system did all the needed checks to never send any funds to non-existing addresses. What happened when you put in the wrong address is that funds went from your account to the scheduler, and before we had to put them back to the accounts. (Will not be the case with the frontend-side crc checks.)
I haven't seen you post any hard math, or hard logic. For example, you "feel" 28 addresses is more secure than 3. Maybe this is the case. Maybe it's bullshit. Did you do any calculations?
Yep, we did some calculations or at least modelling. However we might be wrong somewhere, and some of the premises we have based our service on can indeed be faulty. Noone is perfect. But casascius was trying convince us of *changing* to another way of doing things. And to do that we need some solid basis. You did not seem to see any logic in that particular thing (having fixed size transactions) either.
As for this particular example, if you have 3 addresses that money went to, it's easier to trace than 28 addresses, any of which could be the ones you were looking for. And more importantly, in case with 28 addresses you have more addresses that you know
are not the ones you are looking for, but you don't know which ones.
This is not a valid argument. If your system is secure, then full knowledge of how it operates does not help. If your system is insecure, but you don't tell people how it works, then we can't point out flaws. Eventually an attacker would then break it, through random or intelligent poking.
i.e.; Security through obscurity is no security.
I am not sure about your developer experience, but what you are describing is pretty much the case with client side code, desktop applications, services and such, programs that can and will be disassembled anyways. In that case it is much more secure to make it opensource, where much more people can look for flaws and point them out.
When talking about web applications however, the less the attacker knows, the better. Using your metaphor, the attacker will simply not know where to poke, because he does not have direct access to our code or a compiled binary.
A project like this always uses third party tools, in which bugs can be found that we cannot really control. And knowing what tools, OS, programming languages, or anything really, might give the attacker a better chance of finding such bugs.
However! I am not saying I will not disclose anything else about how the service is built, some things should simply be public using common sense. So please, ask away. I will answer any generic questions about the setup. For example, things like how the payouts are done, what scheme and so should be public of course!
The core though remains, that you've shattered all my trust in your skills at the very beginning, when you didn't implement a core safety mechanism, which is trivial to implement but paramount to prevent mistakes. This mistake, along with your attitude about it the ~5 posts after that, leads me to question a lot of other things about your service, which I might normally assume to be secure/obvious. I can see that casascius's reasoning is similar. (casascius: correct me if I'm wrong)
Well it still seems that you didnt' understand exactly what this flaw could do. (Nothing really, just a little inconvenience for users that gave us wrong information). Or?
If the amount is 7.8, even if we assume your fee could be absolutely anywhere between -0.5% and 2.5% (you DID say 2% before and didn't mention random fee until post #35)... for one, we can be virtually certain that the 3.3 was one of the outputs. Why? The 3.3 is needed for all possible combinations of three that add up to between 7.60 and 7.88.
The 2.67 is also extremely likely, as it's a necessary part of nearly all of the possible combinations that fall in that range. So, two for three... not bad for gumshoe statistical analysis.
Why do you assume there are always 3 transactions? We don't use exactly the same number of transactions for same amounts...
For example we could do 1.8729445434+2.986363423+1.673+1.2352 = 7.76750797
I would say multiple payout addresses would be effective if, by this, it were meant that the recipient provides multiple addresses to be paid, and never combines the funds.
This is the way it works now... Of course it is the recipient that can provide multiple addresses, who else?
And then he should think about not combining the funds. Because, a user COULD for example take funds through our service and then output them to the same amount. That wouldn't be anonymous at all either, and yet we can't really do anything about that. Users MUST be aware of how the bitcoin anonymity works. We have tried to help them with that by explaining things on our page, but that could be done even better I suppose.
As for withdrawing a partial balance... Sure, I suppose. Assuming they forgot about mybitcoin and assume that leaving bitcoins sitting on anonymous services is a good idea. You have heard of MyBitcoin right? And what good is an anonymizing service that only works if you use it a certain unusual way? If all of the security rests on the user remembering to take out a smaller amount than he put in, MtGox is already good for that today.
Oh, but there is a BIG difference here. MTGOX is an official company with official owners, addresses, taxes... They never were nor ever said they would be anonymous. If any problem with the law ever comes up, all their logs will be in the hands of well, you know. Japan is probably as far from the offshore mentality as it gets.
But apart from that, if you would deposit your money to MTGOX, and then manually payout it to your other addresses, manually randomizing all the transactions, then sure, it would be like our service.
We do this automatically, anonymously and without any persisting logs.
And I am sure you know by now that Bitcoins only divide to eight decimal places, and your examples with more than 8 places were just you getting carried away with extra digits.
Yeah, got carried away there, sorry )
) and you are free to do what you want, but I officially endorse you as not knowing what you are talking about. During this duscussion you have had a number of points that I have discredited, and most of them you didn't even bother to answer. In the beginning you didn't seem to even have read up on what exactly our service does, and yet was making assumptions. You don't seem to have a grasp on what other services in the same category do either (they do much less than we do). On top of that, your last argument basically was "ah, you didn't agree with what I said before? I discredit your service!" without giving any actual arguments for what you are proposing.