I would like to start forming a solid foundation for Decred to have anonymity and privacy solutions. I have seen many over engineered solutions for bitcoin, so Id really like to see Decred with a basic toolkit that is solid and reusable. Shared transactions: Multiple users can create a shared transaction where each participant is able to add inputs and outputs. The transaction gets signed by everyone participating. One feature would be to match the other output sizes in the transaction, obscuring the blockchain trail. The tool could work standalone via copy pasting, and could also later support communicate via a msging channels, such as IRC (over tor) for example. Procedure: A msg is sent to a channel, broadcasting that a new transaction is being created. It would specify how long the creator will wait before sending the transaction (ex 20 min). Then other users would join the transaction and submit their inputs and outputs, all parties would agree to the transaction and sign it, but it would not be broadcast to the network until 20 minutes have passed. During that time, further users could join the transaction and add their inputs outputs as well. At any time if a participant was to fail in the negotiation process, the other clients would simply fall back to the last valid transaction. This method is also often called coinjoin, and the best working implementation for bitcoin is here https://github.com/JoinMarket-Org/joinmarket/ . Joinmarket needs a lot of refactoring, is in python2, and implements a market model that is unproven and tends to over complicate what is needed. For decred, it should be a new project in Go like the rest of the code, and not duplicate a lot of the mistakes that joinmarket has made through over engineering. Here is an example of a shared transaction with a simple app for bitcoin, https://github.com/chris-belcher/coinjumble/blob/master/cj-demo.png Rather then going into the more complex solutions out there that other coins are working on, such as confidential transactions and ring signatures, a simple shared transaction tool would be a good place to begin. Build it with simple reusable code, and it will be useful even if other more advanced methods become available later. This may also be good for a future RFP.