zei 0.0.10

Zei: Confidential Assets
# Zei Protocol Outline

## PublicKey based NonInteractive Encryption

We desire to send an ecrypted packet so that only the holder of the secret key accoiated with
a Publickey can unlock the packet. This is used in Zei to send plaintext balance and the blinding used for a transaction.
We assume an authenticated cipher and we use AEAD_CHACHA20_POLY1305.

    Sender -> Receiver (pk)
    1. Sample Some Fresh Randomness (R)
    2. Take pk^R = KEY , this key is used for encryption
    3. Encrypt: ENC(HASH(KEY), message) = cipherText
    4. Send (cipherText, g^R) to recipient
    5. Receiver Must Derive shared key
        5a. Knows g^x = pk. x is secret key
        5b. Recall sender took pk^R as key, thus REDERIVED_KEY == pk^R == (g^x)^R == g^xR == (g^R)^x
    6. Decrypt: DEC(HASH(REDERIVED_KEY), cipherText)

To help bind the blinded curvepoint to the ciphertext, we feed that as part of the Arbitrary length additional authenticated data (AAD). This helps provide another level of integrity to the package as they are both heavly related.

## Proving Commitment Equality

Using a schnorr proof two pederson commitments `C1` & `C2` can be proven to commit to the same scalar `m`. 

A Schnorr proof is a zero knowledge proof of knowledge of a discrete logarithm.

If `C1 = mG + rH` and `C2 = mG + r'H`, then `C1 - C2 = (r - r')H`.

The ZK proof that C1 & C2 commit to the same value is a schnorr proof of discrete logarithm of `C1 - C2 base H`.

Proover: Proof contains two scalars (z, c)

    1. Sample Some Fresh Randomness (R)
    2. c <- Hash(A, H, rH)
    3. z <- ac + r mod p

Verifier: Given a π = (z, c)

    1. Verify c = Hash(A, H, zH - cA)

Using Zei Types we must sum all the amount Blinds in both Input & Output Asset Records.

input_blindes = Sum(OpenAssetRecord.amount_blind)
output_blindes = Sum(OpenAssetRecord.amount_blind)

We Know the total amounts should be equal for inputs and outputs.

`Side note we dont need to take into account fees as they arnt paid through assets in Euka but in capacity`

total_amounts = Sum(OpenAssetRecord.amounts)

H = 

## Batch Equality Proof

This is used to proove that all asset commitments in a transaction commits to the same Asset Flavor.

1. Take both input & output asset commitments for a single asset transaction.


A confidential asset transaction is the following data:
– A list of inputs, which are one of two forms:
• an unambiguous reference to an output of another transaction, with a
signature using that output’s verification key
• an asset issuance input, which has an explicit amount and asset tag;

Associating an issuance with the spend of a UTXO, and a maximum of one issuance per specific UTXO achieves this uniqueness property. The unambiguous reference to the UTXO being spent is hashed together with a issuer-specified value, the Ricardian contract hash[9], to generate the auxiliary input A to the Pedersen commitment.

The Ricardian contract is a machine parseable legal document specifying the conditions for use, and especially redemption of the asset being issued [9]. The details of how such a contract might be designed or enforced is outside the scope of this paper. All that matters for the purposes here is that such a document exists and that its hash is irrevocably committed to in the issuance of the asset.

Every non-coinbase transaction input can have associated with it up to one new asset issuance:

An asset issuance input consists of an UTXO spend I (inter- preted as a non-issuance input of the same transaction); a Ricardian contract C; an initial issuance explicit value v0, or Pedersen commitment H and Back- Maxwell rangeproof P0; and a Boolean field indicating whether reissuance is al- lowed.

Assets may be either of fixed issuance or, optionally, enable later reissuance using a asset reissuance capability. This capability is a token providing its owner with the ability to change the amount of asset in circulation at any point after the initial issuance. When a reissuable asset is created, both the initial asset issuance and the reissuance capability token are generated at the same time.

An asset which supports reissuance indicates this in its asset issuance input, and the transaction contains an additional output of amount 1 which commits to asset tag HA.

Note the parallel to the definition of the asset tag given in Section 4.4, but with the concatenation of a different constant before hashing. In this way an asset tag is linked to its corresponding reissuance capability, and the holder of such a capability is able to assert their reissuance right simply by revealing the blinding factor for the capability along with the original asset entropy.

An asset reissuance input consists of a spend of a UTXO con- taining an asset reissuance capability; the original asset entropy E; the blinding factor for the asset commitment of the UTXO being spent; and either an explicit reissuance amount vi, or Pedersen commitment H and Back-Maxwell rangeproof Pi.

We call attention to the fact that this reissuance mechanism is a specific in- stance of a general capability-based authentication scheme. It is possible to use the same scheme to define capabilities that gate access to other restricted oper- ations. In the authors’ implementation there exists separate capabilities for in- creasing and decreasing issuance, and explicit vs committed reissuance amounts. In general the right being protected could even be made extensible by making the commitment generator the hash of a script that validates the spending trans- action.

// https://github.com/mimblewimble/grin/blob/master/doc/switch_commitment.md

## Switch Commitments

The **ElGamal commitment** scheme is a commitment
scheme similiar to Pedersen Commitments and it's _perfectly binding_ (but only _computationally
hiding_ as we can never have both).
It looks very similar to a Pedersen Commitment, with the addition of a new
element, calculated by multiplying the blinding factor `r` with another generator point `J`:

    v*H + r*G ,  r*J

So if we store the additional field `r*J` and ignore it for now, we can treat it like
Pedersen Commitments, until we decide to also validate the full ElGamal
commitment at some time in future.

A normal Pedersen commitment looks like this:

    v*H + r*G

(`v` is value of the input/output, `r` is a truly random blinding factor, and `H` and `G` are
two generator points on the elliptic curve).

If we adapt this by having `r` not being random itself, but using another random number `r'`
and create the Pedersen Commitment:

    v*H + r*G

such that:

    r = r' + hash( v*H + r'*G  ,  r'*J )
(using the additional third generation point `J` on the curve) then `r` still is perfectly
valid as a blinding factor, as it's still randomly distributed, but now we see
that the part within the brackets of the hash function (`v*H + r'*G  ,  r'*J`) is an
**ElGamal commitment**.

Zei uses Pedersen Commitments with the only difference that the random blinding factor `r` is created using the ElGamal
commitment scheme.

This might not seem like a big change on a first look, but it provides an
important safety measure:

Pedersen Commitments are already _perfectly hiding_ so whatever happens, privacy will
never be at risk without requiring any action from users. But in case of a disaster if the
bindingness of the commitment scheme gets broken, then switch commitments can be enabled 
(via a soft fork) requiring that all new transactions prove that their commitment is not
breaking the bindingness by validating the full ElGamal commitment.