5 ms·

Is that the same as a mixer? If so: sure, they work just fine, except that you've introduced a SPOF who can tell everyone who you are/where it came from/where i

Is that the same as a mixer? If so: sure, they work just fine, except that you've introduced a SPOF who can tell everyone who you are/where it came from/where it went, etc. It's also tough to call something that arose long after BTC itself a "design goal" of BTC. Maintaining proper opsec for any significant length of time is extremely difficult, nigh impossible. Almost everyone will fail at some point. With pseudonymity, a single failure ever means everything is lost. With anonymity, only that single failure is lost.

a1369209993 6y ago
Not taking any position on the rest, but you can mix/tumble cryptocurrency without SPOF: given a specific denomination of bitcoin (eg 1BTC,0.5BTC,0.2BTC,0.1BTC,etc; call it a DIME), set up one or more TOR hidden services with the following interface: .init: generate a new wallet and return its public key, the public key of another wallet (probably one per service for obvious reasons) with at least a DIME to mix and a opaque token identifying (only to you) the pair. .fini: given a token from .init and a transaction that adds up multiple source UTXOs and sends 1 DIME to each of a (sorted) list of wallets that includes the .init-generated wallet, sign that transaction with your source wallet. .link: given a DIME size in BTC and a (.onion) URL implementing this interface at that size, add it to a internal list. .list: given a DIME size, return (possibly a random subset of) the list from .link for that size. For best results you'd need to formalize this interface a bit more and popularize it for better entropy and better plausibility of "well, I guess someone else thought this was a good idea to imitate". Speccing a client to interact with such services (feeding data from .list back into .link and collecting keys from .init to build transactions for .fini) is left as a excersize for the reader. The key point is that you have disposable pseudonyms that will mix their coins with anyone who offers a valid mixing transaction. Assuming there is demand for mixing from anyone other than you (if there's not, you can't really do anything anyway), this captures that demand in order to satisfy your own mixing needs, while also allowing others to bootstrap the exact same trick by adding their own backends via .link. There's QOS and anti-DOS issues to be solved, but it's definitely something that in principle can work.
- jfrunyon 6y ago
  > Assuming there is demand for mixing from anyone other than you And suddenly, it becomes a SPOF for those people.

a1369209993 6y ago

Not taking any position on the rest, but you can mix/tumble cryptocurrency without SPOF: given a specific denomination of bitcoin (eg 1BTC,0.5BTC,0.2BTC,0.1BTC,etc; call it a DIME), set up one or more TOR hidden services with the following interface: .init: generate a new wallet and return its public key, the public key of another wallet (probably one per service for obvious reasons) with at least a DIME to mix and a opaque token identifying (only to you) the pair. .fini: given a token from .init and a transaction that adds up multiple source UTXOs and sends 1 DIME to each of a (sorted) list of wallets that includes the .init-generated wallet, sign that transaction with your source wallet. .link: given a DIME size in BTC and a (.onion) URL implementing this interface at that size, add it to a internal list. .list: given a DIME size, return (possibly a random subset of) the list from .link for that size. For best results you'd need to formalize this interface a bit more and popularize it for better entropy and better plausibility of "well, I guess someone else thought this was a good idea to imitate". Speccing a client to interact with such services (feeding data from .list back into .link and collecting keys from .init to build transactions for .fini) is left as a excersize for the reader. The key point is that you have disposable pseudonyms that will mix their coins with anyone who offers a valid mixing transaction. Assuming there is demand for mixing from anyone other than you (if there's not, you can't really do anything anyway), this captures that demand in order to satisfy your own mixing needs, while also allowing others to bootstrap the exact same trick by adding their own backends via .link. There's QOS and anti-DOS issues to be solved, but it's definitely something that in principle can work.

jfrunyon 6y ago
> Assuming there is demand for mixing from anyone other than you And suddenly, it becomes a SPOF for those people.