Confidential Assets (CA) [[2]](#see-also) extends Confidential Transactions (CT) [[1]](#see-also) to include asset hiding. The BitShares network already understands and validates CT transactions, but is not yet capable of validating CA transactions. The transaction format will need minor to moderate updating and the validation routines will likewise need updating. We propose to either (a) update op-code 39, 49, and 41 to be CA capable, or (b) define new opcodes for CA stealth operations. The latter option probably affords a cleaner upgrade path. The old opcodes should then be disfavored for user wallet use.
A user maintains value-blinded balances on the BitShares blockchain as a collection of Pedersen commitments, which are EC curve points that obscure their committed values by adding a secret blinding factor. By keeping the blinding factor secret, the user keeps their balance secret. Meanwhile, balances can be transferred, subdivided, or combined, provided the sum of blinding factors for all inputs to a transaction are equal to the sum of blinding factors of all outputs of a transaction. A user wishing to un-blind and "claim" a balance contained in a Pedersen commitment may do so by revealing the blinding factor for that commitment, which then allows the network to verify the committed amount.
A commitment C is given mathematically by *C = value * G + blinding_factor * H*, where G and H are separate curve point generators with no known divisor between them.
BitShares is a multi-asset chain. The Pedersen commitments implemented in Stealth Phase I commit only to a value amount, and nothing more. For the network to understand *which* asset is represented by a commitment, a plaintext metadata field is associated with the Graphene object for the commitment, containing the asset ID of the blinded asset. This means that the asset type of an individual blinded balance is publicly knowable.
Confidential Assets (CA) introduces a method for using a hash of the object ID as a confounding factor similar to the blinding factor, such that, unless one already knows the asset represented by a particular Pedersen commitment, one cannot determine the asset from inspection alone. Furthermore, amounts of differing assets can be combined into a single commitment, so that even by tracing the history of a given commitment, one cannot simply divine the asset type by back-tracing to the point where a public asset was blinded. When a user wishes to un-blind an asset, he may do so by providing both the blinding and asset factors for the commitment, so that the network can confirm the contents thereof.
By allowing commitments of differing assets to be mixed together, we achieve two points for privacy: (1) we increase the available mix-in set for diffusion of transaction history, and (2) we make it more difficult for blockchain analysis to determine which assets are being operated on in any given transaction (the more assets involved in the history of a particular commitment, the greater the uncertainty of what the commitment contains).
We propose to add the following three CA operations to the set of valid operations declared in graphene::chain::operation (chain/protocol/operations.hpp). The new CA operations are shown here side by side with their CT equivalents:
On the left are CT operations, whose outputs are value-blinded commitments. On the right are the corresponding CA operations, whose outputs are value-and-asset-blinded commitments. Of special note is op 52, which takes value-blinded CT inputs and outputs value-and-asset-blinded outputs. (As an alternative, op 50 could be made flexible enough to accept either CT or CA inputs, if this proves feasible.) As CA is seen as an upgrade to CT, no op-code is here proposed for transfering from CA back to CT, however in the event of market demand such an operation could be coded.
The Op-Code additions and specifications provided in this document do not conflict with or depend on the details of the ring-signature proposals in [BSIP-1202](bsip-1202.md), as they effect different substructures of the Transaction structure, and therefore both proposals can be implemented independently. This document specifies structures within the Operations vector within a Transaction structure, whereas the ring signature scheme would change the Signatures vector.
(TODO: Check whether preceding is true, i.e. that the operation structure is independent of signature method. If it is not true, include here a discussion of what else might need to be included in the structure, so that a decision can be made as to whether the two features would be best developed in parallel, or whether ring-sigs could be implemented subsequently as an "upgrade" to CA.)
