From 286e8ac44b4e84e414b8aba14c5a85a8b6c26343 Mon Sep 17 00:00:00 2001
From: christophersanborn
<23085117+christophersanborn@users.noreply.github.com>
Date: Wed, 18 Jul 2018 11:42:44 -0400
Subject: [PATCH] Overview of asset surjection proof.
---
bsip-1201.md | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/bsip-1201.md b/bsip-1201.md
index b533828..ab0f020 100644
--- a/bsip-1201.md
+++ b/bsip-1201.md
@@ -53,6 +53,10 @@ _(TODO: QUESTION: How is it ensured that H_{A} is a valid curve point? T
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: