Quote from: ABISprotocol on September 09, 2014, 04:47:43 AM

I'm hopeful that some of the thoughtful development that's occurred with BCN already may find its way into BTC. Indications are that BCN has not gone unnoticed by the bitcoin development community ~ for those who haven't already, see:
Output Distribution Obfuscation, by Gregory Maxwell and Andrew Poelstra (a July 16, 2014 post). (Involves use of cryptonote-based bytecoin (BCN) ring signatures, described as a possibility for bitcoin.)
http://download.wpsoftware.net/bitcoin/wizardry/brs-arbitrary-output-sizes.txt

First of all, I must admit that their idea is worth looking into. However, I'm not sure whether the problem it is trying to solve is relevant when everyone uses the software that uses the protocol properly. BCN automatically splits outputs into standard sums (e.g. 136.7 -> 100+30+6+0.7), so there are plenty of outputs for any ring signature. And if someone forms a transaction manually thereby creating a non-standard output (without splitting) the outcome of such an action is his sole responsibility.

To praise inventors acumen, the scheme they offer does work. It allows to use a single output (amount=V) in different ring signatures with any amount less than V. Namely for every n-value there are floor(V/n) outs of amount "n" and one out of amount "V%n". Receiver is able to recover all private keys for some specific "n", while others can use every possible out public key (for any n-value) in their ring signatures. So that any output can be used in any ring signatures with lesser amount. I won't duplicate the math; it can be found in the paper.

Unfortunately, there are a few drawbacks to the scheme offered.

1) Outputs. BCN has 10-13 outputs per transaction, including the change outs. That's why it is a challenging task to determine the exact amount of an actual transfer and the change. By reducing the number of outputs to 1-3 we lose out on anonymity, just as it is implemented in BTC.

2) "Real"/"ghost" outputs bias. A recipient is tied to a specific n-value (chosen by the sender). When he will have spent all "real" outputs for key P, there will be floor (V/n) outs of amount "n" and one out of amount "V%n". Other users are likely to utilize different n-values and choose them randomly. When analyzing the blockchain i.e. looking for every possible spending of the P-output, a researcher will see a bias in specific n-values. Moreover, it is very likely that a researcher will find that all these "n"-transactions have sum of V which in turn reveals the outs as "real".

3) Shared n-value. Let's leave aside a method of transferring this value to a receiver (the paper does not describe it, implying that the both parties know it). Even if the distribution of n-values is nearly uniform, the sender has an opportunity to trace the subsequent transactions by monitoring all possible spending with "n" value he knows. The additional rule that condradicts the anonymity: i-values should be different when the "real" outputs are spent.

The bottom line is: although the scheme offers smaller transaction size and larger amount of possible outputs it cripples the anonymity feature. All things considered it is not a good trade-off.