Author

Topic: How much capital is typically used for launching mixers/tumblers? (Read 911 times)

sr. member
Activity: 318
Merit: 260
People generally won't utilize new mixers unless they're decentralized. There are simply to many trusted options around.

Anyway, you'd need a large capital to account for the rich.

There isn't such thing as decentralized where all the infrastructure and trust is under one owner(s) which is the case with all I've seen. Multiple trusted parties makes corruption easier. Both increase attack surface and cost-overhead which would be passed on to users.

I also have high-doubts most tumblers to date actually covered in the beginning. I even remember some with a lot of users having trouble with rollover.

Bitmixer.io, BitLaunder.com, Coinmixer.net aren't decentralized and the only obfuscation they have is internal input tagging; all considered the top mixers. Mine does second-level splitting of inputs before it even uses them for mixing and has PCIe hardware isolation of private keys.

There was one mixer once that did what I do but didn't have hardware isolation. I think they were killed by rollover. I forget the name.
sr. member
Activity: 420
Merit: 250
People generally won't utilize new mixers unless they're decentralized. There are simply to many trusted options around.

Anyway, you'd need a large capital to account for the rich.
sr. member
Activity: 318
Merit: 260
It really depends on how many users you have coming in, what you could do is just start with a few BTC then maybe create a changing limit on the maximum amount allowed to be mixed based on how much you have in storage.

Another way is extending timers based on input-performance. This both covers end-user forward-payments and obfuscates the blockchain. As long as other users eventually come in. The only catch is early-users with big exchanges may get mad they have to wait days or weeks while you market the system.

If I were you I'd make sure to avoid doing that, keeping a limit on the mixer at start would be better so people don't have to wait days. Because you may have a large issue on your hands once someone has to wait weeks to get their coins mixed.

The only downside to that model is that big-exchange user can only forward/mix as much as the owner or early users put in. There is also currency lost  do to overhead from distributing inputs to split wallets used for forwards, and do to how fees work designing around this is annoying.
member
Activity: 70
Merit: 10
It really depends on how many users you have coming in, what you could do is just start with a few BTC then maybe create a changing limit on the maximum amount allowed to be mixed based on how much you have in storage.

Another way is extending timers based on input-performance. This both covers end-user forward-payments and obfuscates the blockchain. As long as other users eventually come in. The only catch is early-users with big exchanges may get mad they have to wait days or weeks while you market the system.

If I were you I'd make sure to avoid doing that, keeping a limit on the mixer at start would be better so people don't have to wait days. Because you may have a large issue on your hands once someone has to wait weeks to get their coins mixed.
sr. member
Activity: 318
Merit: 260
It really depends on how many users you have coming in, what you could do is just start with a few BTC then maybe create a changing limit on the maximum amount allowed to be mixed based on how much you have in storage.

Another way is extending timers based on input-performance. This both covers end-user forward-payments and obfuscates the blockchain. As long as other users eventually come in. The only catch is early-users with big exchanges may get mad they have to wait days or weeks while you market the system.
member
Activity: 70
Merit: 10
It really depends on how many users you have coming in, what you could do is just start with a few BTC then maybe create a changing limit on the maximum amount allowed to be mixed based on how much you have in storage.
sr. member
Activity: 318
Merit: 260
I wrote a secure tumbler(hardware isolation for priv. keys on back-end and PDO on a sqllite3 DB with PGP sig given to end-user and simplehttpserver) in python(I have no intention on using it though) and was wondering how people who do these typically handle early transactions? I don't see end-users waiting for other users before they get there coins back so this means the operator has to put in to cover, right? Doesn't this make early users identifiable?
Jump to: