agorise/bsips
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

subsection Asset Tags and Asset Commitments

Browse source
This commit is contained in:
christophersanborn 2018-07-16 11:09:43 -04:00 committed by GitHub
parent dfffa78782
commit 52feaa1fc8
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 23 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
bsip-1201.md
View file

@ -24,6 +24,29 @@ Confidential Assets (CA) introduces a method for using a hash of the object ID a
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, querrying the blockchain for commitment "024449...8073" returns a structure containing three defining fields:
Field: | Data (Meaning)
:----------:|----------
commitment: | "0244492ceafc9c3d6fab34b4e2912b360a3276560651451580325f754705758073" |
asset_id: | "1.3.0" (Core asset, BTS)
owner: | (Authority struct specifying public key that must sign)
Under CA, the `asset_id` field would be replaced by `asset_commit` which is a commitment to an **asset tag**. The asset tag, denoted *H<sub>A</sub>*, is a curve point produced by a hashing procedure of some defining description of the asset (for example the `asset_id`, "1.3.0", etc.). The asset commitment, denoted *H*, is the sum of *H<sub>A</sub>* and a blind point, e.g., _H = H<sub>A</sub> + r*G_. Under this scheme, a CA commitment in the database would look similar to:
Field: | Data (Meaning)
:------------:|----------
commitment: | "0244492ceafc9c3d6fab34b4e2912b360a3276560651451580325f754705758073"
asset_commit: | "022b607af588386028a97d6bc4be5caddb432340329bc808ba587c0b92ffb1087c"
owner: | (Authority struct specifying public key that must sign)
As can be seen, casual inspection of the blockchain does not reveal the unerlying asset, nor even asset tag, since it is comingled 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 transcation (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 H<sub>A</sub> is a valid curve point? There must be some kind of nonce increment in the hash procedure to reject non-curve points. Find out.)_
## 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: