# 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.
2.
//https://blockstream.com/bitcoin17-final41.pdf
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.
