bsips

11 KiB

Raw Permalink Blame History

BSIP: 1201 (unassigned)
Title: New operations for Confidential Asset (CA) transactions
Authors: Christopher J. Sanborn
Status: Draft
Type: Protocol
Created: 2018-01-29
Discussion: <url>

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 blinding_factor 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:

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_A, 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_A and a blind point, e.g., H = H_A + 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 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 H_A 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:

Op-Code	Description	Op-Code	Description
39	transfer_to_blind_operation	49 (placeholder)	transfer_to_ca_blind_operation
40	blind_transfer_operation	50 (placeholder)	ca_blind_transfer_operation
41	transfer_from_blind_operation	51 (placeholder)	transfer_from_ca_blind_operation
		52 (placeholder)	ct_to_ca_blind_transfer_operation

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.

11 KiB Raw Permalink Blame History