You don’t need to be that naive. But how clever do you have to be?
Not at all. The protocols for bitlaundry-type arrangements just have to be updated to add random time delays all throughout. No extra effort on the user’s side.
There’s definitely a lot of extra work, though, that could be done on developing Bitcoin clients that automatically handle stuff like this. (It would have to, without being promted, generate new addresses every so often, and feed them to a service, either which has the time delays, or does it with a patter than would conceal data from traffic analysis.)
“could be” is all very well, but for the people using bitcoin right now, it needs to be “is”.
How long do the delays have to be? Does it matter if the recipient isn’t using a randomisation service? Etc? I’m not saying these questions are unanswerable, it’s just that they need real solid thinking done on them, which (as far as I know, which isn’t very far) hasn’t really been done. And then the answers need implementing.
Not at all. The protocols for bitlaundry-type arrangements just have to be updated to add random time delays all throughout. No extra effort on the user’s side.
There’s definitely a lot of extra work, though, that could be done on developing Bitcoin clients that automatically handle stuff like this. (It would have to, without being promted, generate new addresses every so often, and feed them to a service, either which has the time delays, or does it with a patter than would conceal data from traffic analysis.)
“could be” is all very well, but for the people using bitcoin right now, it needs to be “is”.
How long do the delays have to be? Does it matter if the recipient isn’t using a randomisation service? Etc? I’m not saying these questions are unanswerable, it’s just that they need real solid thinking done on them, which (as far as I know, which isn’t very far) hasn’t really been done. And then the answers need implementing.