Quote from: fusecavator on February 22, 2014, 06:56:08 PM

Quote from: eduffield on February 21, 2014, 11:45:57 PM

Quote from: fusecavator on February 21, 2014, 11:39:29 PM

Quote from: eduffield on February 21, 2014, 03:22:54 PM

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.

I sent this conversation to a friend that is very capable in these fields, and this was his input. For your thoughts/ consideration:
====

I would have gone another way. It would go something like this:

- You submit transaction to block chain

- The block chain server = miner (?) gets your transaction + 100 other transactions

- He sum all and randomly breaks to small pieces and adds to blockchain. So receiver gets coins from 1000 addresses instead of one

- Payment is sent in batches so you do not figure out based on the sum (in case that its 5.34234) that x paid y.

Dealing with transaction id:

- Transaction id is generated client side. probably several ids that need to go with each chunk of coins

- Transaction id sent with the coins to receiver

- There should be some private key public key verification so sender can prove to receiver that he sent the coins. Sender will write in comments $ sent from john and ony receiver can see it.

The only point of failure I can see is if miner keeps log of who sent and where