[ANNOUNCE] Bitcoin Fog: Secure Bitcoin Anonymization

[Akemashite Omedetou]

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.

No that would not be the same thing, because in that case their money would go through just another address, one input, one output, completely transparent.

In case the money goes through us, there are 20 inputs (20 addresses), and 20 outputs (20 payouts, each of which is further split into many transactions and possible going to different addresses), and only one of those inputs and one of those outputs will be theirs, and telling which it was is difficult because nobody has access to our service except for us.

Also, this is the worst-case scenario, where a user is lazy and only withdraws money to one address. This is supported by us, but if the user wants to go for even better anonymity, we also support withdraws to multiple amounts. This was supported from the start.

Also note that using the logic you have used here services like Bitcoin Laundry or other simple randomizers have no purpose at all, yet I don't see you critising them on forums or anywhere else. (Maybe you do though, I just haven't seen it )

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..

1) You don't know the total of any inputs, because inputs can be made to multiple addresses and still go the same Fog account/same withdrawal.
2) Even if you knew the total input, you can't reliably deduce the amount of the output because of
 a) Random fee.
 b) Users don't have to match inputs for outputs. They can put in 10 bitcoins, withdraw 8. Then put in 15 bitcoins more, withdraw 5. Then put in 3 more, withdraw 14, etc... This is what we suggest on our description as well.

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)

Yep. The difference is that in the first case you have 9 outputs in one case and 28 in the second case, the second one obviously being harder to analyze.

The example with the same number of transactions would not be as convincing at all...

Also note that the effect of "(and assume amounts below 0.125 can be swallowed as fees)" is also in place for the randomized transactions because of the random fee. So a different equivalent of those small amounts will be swallowed for each deposit. So NONE of the actual transactions will add up *exactly* to the amount being withdrawn. (Note: it is about the amount being withdrawn, not the amount being put into the system. Those two are not linked in a hard way, as I explained above. So linking those together is yet another hard task an attacker has to do.)

I don't see how having fixed-sized payouts as opposed to randomized (and random precision) helps any anonymity given that total number of transactions is the same. If anyone has mathematical basis for that, please contact us. It would be good to have a solid math for this.

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

Help Build trust

Great! Is that your resource? Is it ok if we put a link to that page somewhere on our website?

[1713986218]

1713986218

[1713986218]

1713986218

[1713986218]

1713986218

[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

Great! Is that your resource? Is it ok if we put a link to that page somewhere on our website?

yes it is. Please do post a link.

[Akemashite Omedetou]

We have now implemented the ability to remove your account. If you are done and have withdrawn your money you can remove the account to remove any traces of you from our service. To do this, follow a link on the profile page (click your username).

Also, all the delaying of payouts issues have been fixed.

Next up: random fee and solid address checking. Up until then we will be returning all the funds to the accounts if you request a payout to an invalid address.

[casascius]

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..

1) You don't know the total of any inputs, because inputs can be made to multiple addresses and still go the same Fog account/same withdrawal.
2) Even if you knew the total input, you can't reliably deduce the amount of the output because of
 a) Random fee.
 b) Users don't have to match inputs for outputs. They can put in 10 bitcoins, withdraw 8. Then put in 15 bitcoins more, withdraw 5. Then put in 3 more, withdraw 14, etc... This is what we suggest on our description as well.

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)

Yep. The difference is that in the first case you have 9 outputs in one case and 28 in the second case, the second one obviously being harder to analyze.

So what you are saying is that if set A had 28 numbers, somehow they would be on par?  Even if the fraction (0.325) couldn't be derived through adding any of them?

It would be totally different if you said, "Aha, I see you point.  I can see how powers of two will eliminate the vulnerability of people being able to deduce which inputs correspond to a given output by elimination based on the fractions".

I probably have criticized, plenty, and I suppose I should be done.

Until further notice, I officially unendorse your service as being unsafe and ineffective for its stated purpose, this post shall serve to memorialize that.  But I wish you the best of luck making it, and I will be happy to update my opinion if I ever change my mind.

[Akemashite Omedetou]

So what you are saying is that if set A had 28 numbers, somehow they would be on par?  Even if the fraction (0.325) couldn't be derived through adding any of them?

It would be totally different if you said, "Aha, I see you point.  I can see how powers of two will eliminate the vulnerability of people being able to deduce which inputs correspond to a given output by elimination based on the fractions".

I am basing my answers on logic, and not on apparent "status" of the person I am talking to.
There is no hard logic to what you are proposing. If you or anyone else has any hard math on this, please provide it. We couldn't find any. And your answer only suggests that it "feels" secure to you, and you don't have any actual models of this. We can't base our secure service on a feel. But since you are being persistent, please do tell me, these are the outputs you see:
2
4
0.25
0.25
4
2
1
2
0.125
2
1
4
2
1
2
in one case
and
2.23454433
1.782252
3.3
1.362
1.6373342
0.8347223
1.2352
0.5243324
2.23
1.8729445434
2.356223
1.673
2.67
2.986363423
1.82786

And you know that a user has deposited 7.8 bitcoins.
Obviously you don't know the fee, it can be 0.03235 or 0.01342345, or 0.0284 or 0.152332 or whatever, it's random.
You don't either know how much of the rest of the amount the user withdraws.
Now please, do tell me which transactions go to this user using the last list and explain how that is less difficult than using the first list.
Or does anybody else see it?

Until further notice, I officially unendorse your service as being unsafe and ineffective for its stated purpose, this post shall serve to memorialize that.  But I wish you the best of luck making it, and I will be happy to update my opinion if I ever change my mind.

It's a free country (we live in the Torland  ) 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.

To conclude, I understand your position, but it does not have any valid basis.

[BTCurious]

I find it strange that only casascius is voicing these concerns over your service. I'd like to state some thoughts that came to mind reading this thread.

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.

Really? Really?
This is such a common and trivial thing to do, any developer who has worked with bitcoin for 3 days will code it as an afterthought to his base58 decode function. It is literally the difference between

Code:

def DecodeAddress(address):
    hex = b58ToHex(address)
    address = hex[0:-4]
    return address

and

Code:

def DecodeAddress(address):
    hex = b58ToHex(address)
    address = hex[0:-4]
    checksum = hex[-4:0]
    if hash(address)[0:4] != checksum:
        error "This is not a valid address"
    return address

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.)

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.

Anything else?… Let's see…

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.

the only checks on addresses we did were for the proper number of characters and proper set of characters

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?

There is no hard logic to what you are proposing. If you or anyone else has any hard math on this, please provide it. We couldn't find any. And your answer only suggests that it "feels" secure to you, and you don't have any actual models of this.

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?

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

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.

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).

This is also not an argument.


About the powers of two/random fractions:
Ideally, when you use your anonymizer, there would be no trace in the blockchain of ever actually using an anonymizer. Considering that, it's probably better not to use powers of two, so in that case I agree with you. (And yes, withdrawing a different amount than depositing does fix the problem of adding up fractions up to a total, as far as I can tell)
For not having a trace on the blockchain, however, this needs to be fixed:

as of now, all payouts are mostly done from the same address

In summary: I think your service does some things right (e.g. the having no public IP, only connecting through tor), while other things seem a bit strange. 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)

[Etlase2]

For not having a trace on the blockchain, however, this needs to be fixed:

as of now, all payouts are mostly done from the same address

I just want to point out that you are asking for security through obscurity. Multiple payout addresses only add obfuscation, not any real security. Anyone looking to find out these addresses need only add their own coins to the pool and follow the trail. Maybe they won't find every thread, but there is no additional guarantee of anything. The weak point is still the service provider.

[casascius]

2.23454433
1.782252
3.3
1.362
1.6373342
0.8347223
1.2352
0.5243324
2.23
1.8729445434
2.356223
1.673
2.67
2.986363423
1.82786

And you know that a user has deposited 7.8 bitcoins.
Obviously you don't know the fee, it can be 0.03235 or 0.01342345, or 0.0284 or 0.152332 or whatever, it's random.
You don't either know how much of the rest of the amount the user withdraws.
Now please, do tell me which transactions go to this user using the last list and explain how that is less difficult than using the first list.
Or does anybody else see it?

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.

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.

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.

[casascius]

For not having a trace on the blockchain, however, this needs to be fixed:

as of now, all payouts are mostly done from the same address

I just want to point out that you are asking for security through obscurity. Multiple payout addresses only add obfuscation, not any real security. Anyone looking to find out these addresses need only add their own coins to the pool and follow the trail. Maybe they won't find every thread, but there is no additional guarantee of anything. The weak point is still the service provider.

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.

With the current client, it would be very difficult to avoid combining them, unless using a multiple-wallet scheme, or paper wallets.  (With paper wallets, I have very detailed control over what inputs go into my transactions, because my bitcoin wallet is always empty except for the coins I have imported for immediate use.  I use a handheld USB QR code scanner to make this easy.)

[Akemashite Omedetou]

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 )

[Akemashite Omedetou]

I am happy to report that we have been running with a randomized fee (between 1 and 3 percent) and full front-end check of the checksum of every bitcoin address for withdrawals for a couple of days, and both features work correctly.
So before if you would enter an invalid address which still looked like a real address, the payment would be scheduled normally and then be stopped in the scheduler so that we would have to manually get money back from the scheduler to your account, now this is checked already at the schedule-withdrawal step, where you get a warning if an address is invalid. As always, double-check your addresses before you finally confirm your withdrawals.

Next up: Using the precision spread that corresponds to the precision of all other transactions seen normally in the block chain, as opposed to randomized precision we use now for all of the payouts.
Also, we are going to implement the calculation of a "max" amount that should be withdrawn per address without it becoming too obvious and issuing a warning if the user wants to withdraw larger amount per bitcoin address.

[marcus_of_augustus]

watching.

[fivemileshigh]

Akemashite, I'm watching bitcoinfog with interest, and I will keep using the service, although only on a trial basis for now. I do wish you all the best in perfecting the service.

Noob question if I may: why is there no way to log out?

[Akemashite Omedetou]

Noob question if I may: why is there no way to log out?

You are right, this has been overlooked. (Here we always use a tor browser that automatically clears cookies all the time, so that hasn't been a problem, that's why.)
Fixed now, added link at the bottom of each page.
Thanks for the tip!

[0ni0ns]

I understand if you don't wish to provide such information, but it would be useful to know statistically how many users you have and how much is in the accounts, so I know that I'm not just mixing our coins with 5-10 people and have a high likelihood of getting my own coins back.

[Akemashite Omedetou]

Yes, we have been thinking about that too. We are now working on a solution that is going to warn a user if he/she is withdrawing larger amounts per address than what should be safe considering current money flow (sum over a couple of days). It should be ready soon.
For now I'll just say that already mixing is done with considerably more people than 5-10, and more and more people seem to get in, which we are glad to see of course.

[fivemileshigh]

I've given bitcoin fog some more thought, and I've decided to hold off on using the service until after you have it display the size of the pool, along with some other trustworthy way to ascertain that i'm not getting my own coins back. The reason is, since it is a paid service, and paid before it is provided, I would like to know for sure that I'm not getting my own coins back, otherwise the service is hardly worth the cost.
I'll try to keep watching this thread.

[Explodicle]

I've given bitcoin fog some more thought, and I've decided to hold off on using the service until after you have it display the size of the pool, along with some other trustworthy way to ascertain that i'm not getting my own coins back. The reason is, since it is a paid service, and paid before it is provided, I would like to know for sure that I'm not getting my own coins back, otherwise the service is hardly worth the cost.
I'll try to keep watching this thread.

I like the first idea for pool size, but keep in mind that a truly randomized service should still SOMETIMES give you some of your own coins back. Otherwise, over time someone watching both ends could establish a possible connection.

[Akemashite Omedetou]

I've given bitcoin fog some more thought, and I've decided to hold off on using the service until after you have it display the size of the pool, along with some other trustworthy way to ascertain that i'm not getting my own coins back. The reason is, since it is a paid service, and paid before it is provided, I would like to know for sure that I'm not getting my own coins back, otherwise the service is hardly worth the cost.

We respect your choice, but about this “my own coins back” thing, please consider looking through the section we have about this on bitcoinfog.com. There is no concept of “somebody’s coins” in the block chain and it is impossible to get “your own” coins back. For example consider if you put coins on a bitcoin address and get your privkey to someone else so he will be able to use the money. Are they still your coins? On the contrary, if you transfer some bitcoins between different addresses a couple of times, they would logically still be your coins, but to an outsider that could easily look like you have bought something with them and they went to some else’s possession.

I think what you are referring to is whether you get paid back from the same address that you have deposited your funds to. This never happens with our service, which you can easily see in the block chain explorer if you do a withdrawal. Depending on random parameters, any of the addresses that you did deposit your coins to may or may not be included down the line in the flow of bitcoins that eventually are paid back to you to your withdrawal address (which is built like this exactly because of what Explodicle said), but are never paid back directly from the same address they were deposited to, and are never paid back unmixed with some other coins from other addresses first.

On an unrelated note, we would like to thank all the users that have been using our service. From some time before the new year we have seen a substantial increase in usage, which would mean that the users were not only coming from the first page of the forum (when the topic was there), and it could only mean good news for us. We are happy to see that a service like ours is indeed seems to be needed and will keep working to stay on the edge. We are still a pretty young service of course, and we fully understand if some users are suspicious at first.

[slush]

Can you publish daily/weekly/monthly amount laundered on the site? I think it's important for the people to know they're not alone using this service, which breaks the anonymity. I think *this* was the concern of fivemileshigh.