Show Posts
Mixing beta is released on IRC in #team-tips on freenode, a web-client is at https://kiwiirc.com/client/irc.freenode.net/#team-tips
Now that we've had confirmation it works, time to announce the new feature we've been working on.
As you can see at the image at http://imgur.com/TjgdW4h, a new "Mix Coins" option has been added to the wallet.
That's right, you can now mix coins directly from the wallet! Coins you send to people can be transparently sent to a mixing node, which will then queue the transaction and every 7 minutes send the queued transactions out to the destinations. RPC consumers can also make sure of the mixing feature by setting the "mix" parameter in the sendtoaddress/sendfrom/sendmany commands to true.
In case you don't know what coin mixing is, it allows you to mix up the coins you send to someone and make their origin completely untraceable.
Right now we only have one mixing node online which is operated by me. By release we hope to be able to support many mixer nodes, so long as they get approved by the development team first. Allowing anyone to start a mixing node would be nice but there's a lot of risks that involves... If in the future we can mitigate those risks we will do it as soon as we can, but the current architecture doesn't really lend itself to having completely trust-less coin mixing.
Why?
What with governments and other entities starting to become more and more aware of cryptocurrencies it's become apparent that they, along with services such as Coin Validation, seek to disturb the pseudo-anonymous nature of cryptocurrency. By attempting to track down coins and keep a paper trail of where they've been, they're trying to turn cryptocoins into another glorified credit card provider, allowing governments, law enforcement officers and people-with-the-right-friends to track down where you've spent your coins at.
Hearing about this unsettled me, it seemed to me like they almost wanted to destroy the very nature of cryptocoins. I first heard about this when I started using StableCoins, the developer of that coin had announced plans for a mixing feature of his own, giving a detailed write up about why it's needed (the writeup is available at https://bitcointalk.org/index.php?topic=353971 it's a very good read and should help you realize why mixing features are important).
As a holder of StableCoins I waited a long time for the mixing feature of StableCoin to come about, but after some sad months of waiting and hearing almost nothing from the developer, I decided to try adding it myself. After around a day or so of straight coding (and energy drink abuse
) FedoraCoins mixing feature was born.Release information
A release will be coming very soon, I only have to clean up a few rough parts on the wallet, add multi-mixing node support and ensure everything works. Once all that's done we can make a full public release.
Until that time there's a beta version available for testing on IRC. Join the room #Team-TIPS on freenode to take part.
The beta currently only supports the mixing nodes that I operate, but the full public release should either allow you to choose what node to use, or choose the node randomly (haven't decided yet, join #Team-TIPS if you have any ideas!)
Also, for anyone wondering, this doesn't cause a hard fork
I worked hard to ensure that older clients will still accept mixed transactions, and it looks like that work paid off.A small note: Due to this feature not being planned from the outset of FedoraCoin there was no pre-mine or even any attempts to gather coins for the mixer. The beta node currently has around 10 million TIPS to mix with, which is hardly a lot considering many people own 500 million or more.
If you feel that this mixing idea would be good for FedoraCoin feel free to donate to the mixer node, the main address used by it is ETSzZNZyAt1XhbKUReneEb5YkmMjVXTzBy
Technical explanation / use case
Mixing nodes are split into two parts, a sender node and a receiver node, these two nodes are in two different locations completely apart from each other and only communicate to each other via Tor.
Alice sends a transaction to Bob's address with the mix option turned on
Transaction is sent out (transparently) to the mixing receiver nodes address, to Alice it'll show in history as a transaction sent to the mixer.
Transaction outputs in the transaction are exploited to store the mixing data (to allow older clients to accept the transaction), encrypted with the receiver nodes public key.
Receiver node receives the transaction and decrypts the destination addresses with its private key
(at this stage the Receiver node knows Alice's address, Bob's address and the amount)
Receiver node checks if the sender node has enough coins, using RPC over Tor. If it doesn't the sent coins are refunded.
Receiver node queues the transaction.
Every 7 minutes on the receiver node, the node sends all the queued transactions to the sender node via RPC, over Tor to ensure their communication is private.
(once the queued transactions are sent the receiver node removes all traces of the decrypted transaction data, only storing hashes of the transaction ID and destination address to aid with problems such as missing coins. Since they're hashed there's no way to identify where they were going unless you already know the destination)
Sender node's RPC daemon receives the send coin request and checks the RPC connection info (user/pass/etc) to ensure it's from the receiver. If it's invalid it disregards it.
(at this stage the Sender only knows Bob's address and the amount, not Alice's address)
Sender node sends the coins as a normal transaction to the destination address (the sender node would also have all of it's balance split between different addresses for extra security)
Bob receives the coins, with no connection to Alice recorded on the blockchain at all.
Alice's address is recorded to have used the coin mixer, but thanks to the public-key encrypted transaction info the destination of the coins cannot be found.
Risks
Node may be compromised:
- The Receiver doesn't send any communications out to the network at all, it only listens to the network.
The only communications it makes are to the Sender over Tor, so there is no way to trace it back and find where the Receiver node is
- The only node that would be connected to the destination is the Sender, so any investigators would only be able to track the Sender (if at all)
- The Sender node only knows about the destination address and the amount, not who sent it
- The sender of the coins (Alice) can rest assured that nobody would be able to find out that they sent the coins, unless the Receiver node was compromised, which is an almost 1 in a billion chance as it only listens to the network and communicates over Tor.
Thanks for reading this, I hope you'll find coin mixing as useful as I've designed it to be!
ha ha" without giving any factual reasons will be banned however)
We might be adding a new difficulty algo in soon though (gravity well sounds interesting, it sorta sounds like what we were planning on in the beginning) which should help us combat multipools.
