Open christophersanborn opened 6 years ago
(TODO: QUESTION: How is it ensured that HA is a valid curve point? There must be some kind of nonce increment in the hash procedure to reject non-curve points. Find out.)
According to [2], H_a is created by a "point valued" hashing function, so H_a is on the curve by definition. It seems that the implementation in secp256k1-zkp takes a fixed value for x and computes the corresponding y so that the result is on the curve.
It seems that our copy of secp256k1-zkp does not contain a primitive for preparing the pedersen commitment context with an arbitrary auxiliary value.
According to [2], H_a is created by a "point valued" hashing function, so H_a is on the curve by definition. It seems that the implementation in secp256k1-zkp takes a fixed value for x and computes the corresponding y so that the result is on the curve.
True, but we need to generate X values which are themselves on the curve. Not every X value has a corresponding Y value. (For every x, there is a corresponding y^2 = f(x), but not every y^2 has a solution in the prime field.)
We can of course take an asset description and hash it with, e.g., sha256, and interpret the result as an X value, but if that X value is not on the curve then some additional step needs to be part of the definition. Increment X until you hit one that's on-curve? Hash again and try again until you hit one that's on-curve? A simple procedure is likely already documented somewhere, and I'd say we should copy that, else just pick a process and document it here. I haven't yet gone deep into the Elements Sidechains code, but I'd guess they've got their "point-valued hash" in there somewhere.
It seems that our copy of secp256k1-zkp does not contain a primitive for preparing the pedersen commitment context with an arbitrary auxiliary value.
Interesting. The latest copy in Elements might have it.
Draft merged.
(From: https://github.com/Agorise/bsips/blob/master/bsip-1201.md)
Abstract
Confidential Assets (CA) [2] extends Confidential Transactions (CT) [1] 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.
Confidential Assets is a new, but not un-tested, technology. The Elements Project [3] maintains an experimental implementation [4] of CA as a Bitcoin side chain. The code for that project is MIT-licensed and can help guide the implementation of CA in the BitShares ecosystem.
This BSIP is one of several describing Stealth development, Phase II.
Motivation
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 times a generator point. 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 and credit it to a public balance.
A commitment C is given mathematically by _C = value H + blinding_factor G_, where H and G are separate curve point generators with no known divisor between them. Because there is no known multiple m solving H = m*G, the value and _blindingfactor quantities are effectively independent, which makes C a firm commitment to value.
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 commitment to a hash of the asset description 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 in a single transaction, so that the asset IDs of the outputs are not individually knowable. Thus, 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, as the history may implicate multiple asset types. When a user wishes to un-blind an asset, he may do so by providing both the value blinding factors and the asset blinding 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).
Rationale
Asset Tags and Asset Commitments
The existing value-blinded CT transaction capability includes an explicit asset ID in the transaction format, and unspent commitments are associated with an explicit clear-text asset ID in the database. For example, querying the blockchain for commitment "024449...8073" returns a structure containing three defining fields:
Under CA, the
asset_id
field would be replaced byasset_commit
which is a commitment to an asset tag. The asset tag, denoted HA, is a curve point produced by a hashing procedure of some defining description of the asset (for example theasset_id
, "1.3.0", etc.). The asset commitment, denoted H, is the sum of HA and a blind point, e.g., H = HA + r*G. Under this scheme, a CA commitment in the database would look similar to:As can be seen, casual inspection of the blockchain does not reveal the underlying asset, nor even asset tag, since it is commingled with a blinding factor. The only way to know the asset id would be if the commitment were a direct descendent of an asset-issuance transaction (where a public balance was blinded into a value-asset blind CA commitment). However, once a commitment is involved in a transaction involving inputs of multiple asset types, then uncertainty is introduced in the descendent commitments: the asset type will be one of the parent asset types, but which one is unknowable except to parties that know the blinding factors.
(TODO: QUESTION: How is it ensured that HA is a valid curve point? There must be some kind of nonce increment in the hash procedure to reject non-curve points. Find out.)
Range Proofs and Surjection Proofs
Since the committed values in the Pedersen commitments are unknowable to parties not privy to the blinding factors, there exists the possibility for a transaction resulting in two or more outputs to encode a negative value in one output and an excess positive value in the others, resulting in inflated (i.e., counterfeit) asset supply. To prevent this, transactions with more than a single output are required to provide a range proof for each output, which is a zero-knowledge proof that the committed value is in a finite range between zero and an upper bound that won't risk overflow into negative values. (Values are encoded as 256-bit unsigned integers such that very-large integers "wrap around" and behave as negatives. Range proofs typically prove that a committed amount can be represented in 64-bits or less, affording no risk of overflow.) Under CA, the requirement to provide a range proof remains the same as under CT.
A new requirement in CA is the asset surjection proof. Similar to range proofs, ASPs prove that a validity contstraint is met on the blinded asset commitments of the transaction outputs. Specifically, it proves that the asset tags of the outputs match the asset tags of the inputs, without revealing what those tags are or which outputs correspond to which inputs. (TODO: preceding is imprecise.)
(TODO: discuss space requirments of ASPs, since they do add to transaction size. Compared to range proofs already included in CT transactions, however, they are comparatively small, except perhaps in the case of a large number of inputs and outputs in a single transaction.)
Specifications
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 transferring from CA back to CT, however in the event of market demand such an operation could be coded.
Proposed operation: transfer_to_ca_blind_operation (Public to Blind)
Proposed operation: ca_blind_transfer_operation (Blinded to Blind)
Proposed operation: transfer_from_ca_blind_operation (Blind to Public)
Discussion
Compatibility with ring-signature scheme
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, 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.)
Asset surjection and compatibility
TODO: Question: Are Asset-Surjection Proofs compatible with a Ring-Sig scheme? I.e., can a prover who is "accusing" unrelated inputs produce the proof even not knowing the blind factors and asset tags of the unrelated inputs?
Summary for Shareholders
Copyright
This document is placed in the public domain.
See Also
[1] Confidential Transactions (Greg Maxwell) - https://people.xiph.org/~greg/confidential_values.txt
[2] Confidential Assets (Poelstra, et. al.) - https://blockstream.com/bitcoin17-final41.pdf
[3] Elements Project - https://elementsproject.org
[4] Elements Project on GitHub - https://github.com/ElementsProject/elements