Just as I'm getting over my migraine from learning about Confidential Transactions at a high level we get another awesome proposal. When I first saw your request for compensation on the CoinJoin thread I thought you were just another crank and/or weirdo (The jury is still out.). I would very much like to see a proof of concept.
Some comparisons between these two new proposals.
CCT transactions are smaller than CT transactions, though it's not as easy as just saying one is X% smaller than the other;
Since the introduction of multi-signature addresses, the average Bitcoin transaction size has risen to about 600 bytes. For a typical two input, two output
transaction, the value hiding enhancement adds two commitments of 33 bytes
each, two smallness proofs of 132 bytes each and two encrypted values of 32
bytes. In net terms, about 400 bytes (66%) are added. While this grows quickly
with the number of outputs, only one commitment (33 bytes) needs to be kept
in each unspent transaction output.
The result is that a proof for a 32-bit value is 2564 bytes, and simultaneously may convey 2048 bytes of message. A 32-bit proof can cover a range of 42.94967296 BTC with 1e-8 precision, or 429.4967296 BTC with 1e-7 precision, and so on.
The required commitments are an order of magnitude smaller than those proposed for Confidential Transactions, hide the whole value rather than only the mantissa, and do not depend on ring signatures.
I thought that CT represented the entire value in the mantissa, so isn't this a distinction without a difference?
CT amounts are expressed using a decimal floating point where the digits are multiplied by a base 10 exponent. This means that you can prove large amounts with small proofs, so long as they have few significant digits in base 10: e.g., 11.2345 and .0112345 can have the same size proof, even though one number is a thousand times larger.
CT implementation (Well commented.);
https://github.com/ElementsProject/secp256k1-zkp/commit/bd067945ead3b514fba884abd0de95fc4b5db9aeThere is no CCT implementation.
CCT, unlike CT, offers some consideration to miners;
4.2 Coinbase If coinbase subsidy could be both randomised similar to Luckycoin (and earlier version of Dogecoin), and hidden while proved in a narrow range, this could provide extra initial privacy for the miners. This is considered too expensive to implement. The coinbase is instead constrained to be spent into a minimum of 3 outputs. This ensures that a miners payee will not be able to determine the exact amounts sent to other payees from the single transaction output. 4.3 Sender and receiver responsibilities Sender and receiver must not disclose the view key, amount and fuzz bits used in each transaction. It is up to the sender of a transaction to guarantee its secrecy by generating good randomness for the fuzz bits of each output. Once the details of a transaction are made public, it is likely that they can not be hidden again.
They both use a zero knowledge proof to ensure that the commitments don't overflow in an homomorphic addition.
Beyond that I'm certainly not qualified to comment so read further at your own risk. One of the neat things about CTT is that the only thing that needs to be stored permanently on the blockchain is the commitment to a value. The value itself is encrypted via Elliptic Curve Cryptography and can eventually be dropped, as it is only needed by the receiver. Allegedly the "proof of smallness" can also be dropped.
CT does not have this same ability to prune because the encrypted value is tied to the commitment. The "range proof", as Greg Maxwell calls them, could likely be dropped in the same way CCT can.
Can CCT be used to encrypt other arbitrary information as well, or is it limited to transaction values?
Cool times in cryptocurrency land.
http://voxelsoft.com/dev/cct.htmlhttps://bitcointalk.org/index.php?topic=1085273.0