Other ideas?
Im open to ideas on how to provide the best security to the network. I would love to hear what people have in mind.
How about adding an option for adding decoy transactions?
Sometimes coinjoins can be picked apart just by looking at what adds up. This was painfully obvious on the darksend testnet the other day, as I remember seeing darksend transactions like Inputs: 500, 5 Outputs: 400, 100, 4, 1 where there's only one possible solution of who sent what.
One could easily construct decoy transactions to specifically add up to the amounts of the legit transaction. For example:
Intended transaction:
Input: 100
Output: 20, 80(change)
Decoy transaction:
Input: 500
Output: 10, 90, 50, 50, 35, 65, 95, 5, 100(all sent to change addresses)
If that decoy transaction is coinjoined with the intended transaction, there becomes 5 extra possibilities of where the 100 was sent to even if no transactions by others help mask it
Also, use more inputs than necessary, and use several change addresses instead of just one to help mask the intentions, and also having more and smaller outputs causes it to be more likely that they can be useful to help mask other transactions joined with them.
The testing we did was just a test of the transaction pooling and remote signing of inputs, not a test of anonymity (good eye though checking that out). One of the next tests we should have that working.
Heres the plan for anonymizing amounts if anyone is interested:
DarkSend anonymizes unique amounts like 15.15 by using denominations of currency in the different transaction pools available. These denominations come in the amounts of 5000, 1000, 500, 100, 50, 20, 5, 1, .50, .25, .10, .05, and .01. For example a payment of 15.15 would be broken down and submitted to the following transaction pools:
Submit payment for 10DRK to addr Xyz using pool 10 (in pool 10 ALL outputs are for 10DRK)
Submit payment for 5DRK to addr Xyz using pool 5 (in pool 5 ALL outputs are for 5DRK)
Submit payment for 0.10DRK to addr Xyz using pool .10
Submit payment for 0.05DRK to addr Xyz using pool .05
The four payments total 15.15, just like paying in cash, except you have no idea who paid you.
Users receiving anonymous payments will then receive separate out of order payments for various amounts adding up to the total amount they were intending on receiving.
With this methodology, payments could be as granular as 0.01, this could be changed in the future if the currency becomes more valuable by adding smaller denominations.
That sounds great, and far better than anything I thought of. Your denominations seem a little weird though. Several of them have rather limited usefulness ( 0.25 -> 0.5 -> 1 is only double each step), and the lack of pools for very low amounts seems like a strange choice. Is there a reason you have all those close amount pools rather than a pool for each 10^n? (1, 10, 100, 1000, 0.1, 0.01, 0.001, etc)
Decoys might still improve that pooling system though. As the payment is broken down, an address belonging to the sender and the output of the send will end up in a transaction together for each part. If the sender has received most or all of the coins to one address, or if someone watching knows multiple of the sender's addresses, they might be able to connect the source and destination by looking at if known addresses of the sender, and any output, are always in the same transaction with each other over the duration of the transaction. By using decoy sends, you can add in parts where the sender's addresses are seen in a block, but the intended destination is not, making analysis more difficult.
