Improvement on Spec

[BoyuanFeng]

I suggest an update on the notation in Definition 4.1.7.

1. We need to specify the meaning of t, z, and w.
2. We need to use a consistent notation for t v.s. $I_i$, and $z$ v.s. $z_i$.
3. What is the meaning of "accumulated values" $z_i$ and $\texttt{current}(s_i)$? The text is not very self-explained.

Please see Definition 4.1.7 below.

[stechu]

Thanks! A PR is welcomed!

[BoyuanFeng]

A few suggestions on Definition 4.3.2 ~ 4.3.5:

1. Before Definition 4.3.2, we may add a paragraph on the setup before starting Transfer. In particular, when/how/who to generate sk, rk, esk, epk. At the beginning, I thought that receiver need to send rk to sender for transaction. However, after reading it several times, I realize that both sender and received have their own (sk, rk, esk, epk). This should be clarified in the beginning.

2. In Definition 4.3.2 (Transfer Sender), we have an encrypted message (epk, C_{note}): EncryptedNote. In Definition 4.3.4 (Transfer Receiver), we have R.note = HPKE.encrypt(R.rk.view, R.esk, (R.esk, R.asset)) and note: EncryptedNote. We should make the notation C_{note}, note, and R.note consistent.

3. R.note in Definition 4.3.4 is indeed not EncryptedNote type. We still need an additional epk for the EncryptedNote.

[BoyuanFeng]

A few suggestions on Definition 4.3.8 ~ 4.3.10:

1. [Critical]: In Definition 4.3.4 ~ 4.3.5, we mentioned the generation of R.note and include R.note in Transfer Receiver Post. However, generating R.note is not included and proved in Definition 4.3.8 (Transfer Validity Statement). This may lead to some problems. For example, the receiver may use a correct asset (e.g., 0.1 Bitcoin) in generating UTXO (a.k.a. R.cm), such that this is a valid transfer. However, the receiver may use a totally different asset (e.g., 100000 Bitcoins) when generating R.note and include this malicious R.note in the Receiver Post.

2. In Definition 4.3.2 ~ 4.3.8, who will generate the Transfer Sender Post and Transfer Receiver Post? My understanding is that the sender and the receiver independently generate these two posts. We need to clarify that.

3. We may add a few words on why we need R.note. My understanding is that this is for account auditing purposes. We need to specify that somewhere between Definition 4.3.3 ~ 4.3.9.

4. In Definition 4.3.9 (Transfer Post), who will generate zkp \pi? My understanding is that sender will generate zkp \pi. We need to clarify that.

5. [Critical]: In Definition 4.3.8 (Transfer Validity Statement), we need to check cm_z equals True. Otherwise, a malicious guy can simply set cm_z as False and use a S.cm that does not exist in the ledger.

6. Wih \pi in Definition 4.3.9 (Transfer Post), why do we still need cm_z in Definition 4.3.3 (Transfer Sender Post)? If Transfer Post is valid, cm_z should always be True?

7. In Definition 4.3.10 (Ledger-side Transfer Validity), we check Current Accumulated State in terms of the UTXOSet.Output stored in each P.senders. How to achieve that? This is not included in either Sender Post or Transfer Post.