From 52feaa1fc8dd442e152a2a5dba8fae8b98a98009 Mon Sep 17 00:00:00 2001
From: christophersanborn
 <23085117+christophersanborn@users.noreply.github.com>
Date: Mon, 16 Jul 2018 11:09:43 -0400
Subject: [PATCH] subsection Asset Tags and Asset Commitments

---
 bsip-1201.md | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/bsip-1201.md b/bsip-1201.md
index 85996ca..1c8ed40 100644
--- a/bsip-1201.md
+++ b/bsip-1201.md
@@ -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: