Update docs and add a check in PoB

Author: lovesh

dart-bp/docs/1.md

@@ -10,11 +10,11 @@ The scalar field of $\mathbb{G}_p$ is $\mathbb{Z}_p$ and its base field is $\mat
 
 The following are the group generators (curve points):
 
-$G, G_i, H, H_i, J_0, J_1 \in \mathbb{G}_p$
+$G, G_i, H, H_i, J_0 \in \mathbb{G}_p$
 
 $\widetilde{G}, \widetilde{G}_i, \widetilde{H}, \widetilde{H}_i \in \mathbb{G}_q$
 
-The generators $G, G_i, \widetilde{G}_i, H, H_i, J_0, J_1, \widetilde{H}, \widetilde{H}_i$ can be derived using a hash-to-curve method.
+The generators $G, G_i, \widetilde{G}_i, H, H_i, J_0, \widetilde{H}, \widetilde{H}_i$ can be derived using a hash-to-curve method.
 
 For a point $P$, the notations $P.x$ and $P.y$ refer to its $x$-coordinate and $y$-coordinate, respectively.
 
@@ -190,7 +190,7 @@ The encryption key is only used to decrypt the transactions while affirmation ke
 
 This also allows for a situation where the investor can have a custodian who has the affirmation key and investor with only the encryption key can see all transactions created for him. Even if a malicious settlement creator and custodian collude, they cannot create a settlement involving the investor which the investor can't decrypt.
 
-An encryption key can be shared between auditors and mediators. In that case, the $\mathrm{EK}$ appears in the asset leaf as an auditor key, and the mediator's leaf entry references it by index $\mathrm{idx}$. This way they both use the same $\mathrm{EK}$ to decrypt leg encryptions. Sharing encryption keys makes settlement creation proofs cheaper.
+An encryption key can be shared between auditors and mediators. In that case, the $\mathrm{EK}$ appears in the asset leaf as an auditor key and the mediator uses it to decrypt leg encryptions. Which encryption key a mediator holds is kept private — a mediator's affirmation key is broadcast-encrypted to every $\mathrm{EK}$ of the asset, so no encryption-key index is stored in the leaf. Sharing encryption keys makes settlement creation proofs cheaper.
 
 All public keys are in the Pallas curve.
 
@@ -283,16 +283,16 @@ Note that in the new state $\mathrm{State}_{i+1}$, fields $\mathrm{sk}, \mathrm{
 The system uses curve trees as accumulator and has 3 curve trees.
 
 1. Asset curve tree: Each leaf of this tree corresponds to an asset and stores the $\mathrm{asset\_id}$ and the public keys of its auditors and mediators. When issuers register a new asset, a new leaf is added to this tree. When they update existing asset, their leaf is updated accordingly.
-   A leaf of the asset tree is a group element in $\mathbb{G}_q$ and thus a point on Vesta curve. It is a non-hiding Pedersen commitment to the x-coordinates of several points in $\mathbb{G}_p$:
-   $$\mathrm{Leaf}_{\mathrm{asset\_id}} = (P_0.x) \cdot \widetilde{G}_0 + (P_1.x) \cdot \widetilde{G}_1 + \dots + (P_{n+m}.x) \cdot \widetilde{G}_{n+m}, \quad \mathrm{Leaf}_{\mathrm{asset\_id}} \in \mathbb{G}_q$$
+   A leaf of the asset tree is a group element in $\mathbb{G}_q$ and thus a point on Vesta curve. It is a non-hiding Pedersen commitment to both coordinates of several points in $\mathbb{G}_p$ (two generators per point), followed by the mediator count $m$ committed as a scalar under one trailing generator:
+   $$\mathrm{Leaf}_{\mathrm{asset\_id}} = \sum_{i=0}^{n+m} \left( (P_i.x) \cdot \widetilde{G}_{2i} + (P_i.y) \cdot \widetilde{G}_{2i+1} \right) + m \cdot \widetilde{G}_{2(1+n+m)}, \quad \mathrm{Leaf}_{\mathrm{asset\_id}} \in \mathbb{G}_q$$
    where the points $P_i \in \mathbb{G}_p$ are constructed as:
-   - $P_0 = \mathrm{asset\_id} \cdot J_0$
+   - $P_0 = (\mathrm{asset\_id} + 1) \cdot J_0$ (the $+1$ offset keeps $P_0$ off the identity even when $\mathrm{asset\_id} = 0$, which committing both coordinates rejects)
    - For each of the $n$ auditor (encryption) keys $\mathrm{EK}_i$: $P_i = \mathrm{EK}_i$
-   - For each of the $m$ mediator keys $\mathrm{MK}_j$ with its associated encryption key index $\mathrm{idx}_j$: $P_{n+j} = J_0 + J_1 \cdot \mathrm{idx}_j + \mathrm{MK}_j$
+   - For each of the $m$ mediator keys $\mathrm{MK}_j$: $P_{n+j} = \mathrm{MK}_j$ (the bare affirmation key)
 
-   The generators $J_0, J_1 \in \mathbb{G}_p$ are public. The $J_1 \cdot \mathrm{idx}_j$ term encodes which of the asset's encryption keys is associated with mediator $j$. Mediators have both an encryption key (shared with auditors, for decrypting the leg) and an affirmation key $\mathrm{MK}_j$ (for signing their decision). The leaf encodes both by combining them into a single point.
-   
-   As with the account trees, x-coordinates are taken by adding a public $\Delta$ before taking the x-coordinate.
+   The generator $J_0 \in \mathbb{G}_p$ is public. Mediators have both an encryption key (shared with auditors, for decrypting the leg) and an affirmation key $\mathrm{MK}_j$ (for signing their decision); the affirmation key goes in the leaf as a bare point, and which encryption key a mediator shares is not stored — only the mediator count $m$ is committed, under the trailing generator.
+
+   Unlike the account trees (whose leaves are committed by their x-coordinate after adding a public $\Delta$), the asset leaf commits both coordinates of each point and no $\Delta$ shift is used. Committing both coordinates pins each point fully; committing only $(P_i + \Delta).x$ would leave the y-sign free (see the "Pedersen Commitment to Curve Points" protocol in 4.md).
 
 2. Fee account curve tree: Each leaf of this tree corresponds to an account state for a fee paying asset. As fee payments are done, existing states of those accounts are invalidated by revealing the nullifier (more on that later) and new states are added. A leaf of this tree is an account state as:
 

dart-bp/docs/2.md

@@ -132,8 +132,9 @@ Above are the high level instance and witness values known before the protocol s
    $$\rho_{(\mathrm{chunks}_0)_r} \cdot H_{\mathrm{NC}+1} + \dots + \rho_{(\mathrm{chunks}_{\mathrm{NC}-1})_r} \cdot H_{2 \cdot \mathrm{NC}}, \in \mathbb{G}_p$$
 
 12. Prover hashes the following to create challenge $c$ as:
-    $$c = \mathrm{Hash}(\mathrm{State}_0, \mathrm{AK}, \mathrm{EK}, \mathrm{at}, \mathrm{ctr}, N, \mathrm{id}, C_{s_i}, C_{\rho_i}, \mathrm{pk}_T, \mathrm{Com}_s, \mathrm{Com}_\rho, C_{\mathrm{BP}_\rho}, C_{\mathrm{BP\_s}\_\rho}, $$
+    $$c = \mathrm{Hash}(\mathrm{State}_0, \mathrm{AK}, \mathrm{EK}, \mathrm{at}, N, \mathrm{id}, C_{s_i}, C_{\rho_i}, \mathrm{pk}_T, \mathrm{Com}_s, \mathrm{Com}_\rho, C_{\mathrm{BP}_\rho}, C_{\mathrm{BP\_s}\_\rho}, $$
     $$T_{\mathrm{state}}, T_{\mathrm{null}}, T_{s-\mathrm{combined}}, T_{\rho-\mathrm{combined}}, T_{\mathrm{enc}_i}, T_{\mathrm{chunks}_i}, T_{\mathrm{BP}_\rho}, T_{\mathrm{BP\_s}\_\rho}, T_{\mathrm{pk}}, T_{\mathrm{EK}})$$
+    Note: $\mathrm{ctr}$ is a public input (part of the instance) but is not hashed into the challenge; it is bound to the proof through the Poseidon2 R1CS constraint $\rho = \mathrm{Poseidon2}(\mathrm{rho\_randomness}, \mathrm{at}\mathbin{\|}\mathrm{ctr})$, where $\mathrm{at}\mathbin{\|}\mathrm{ctr}$ is the public constant supplied by the verifier — so a wrong $\mathrm{ctr}$ fails the circuit.
 13. Prover now creates responses for each sigma protocol as:
     $$\mathrm{resp}_{\mathrm{state}} = [\begin{matrix}
  \rho_r + \rho \cdot c, & \rho^2_r + \rho^2 \cdot c, & s_r + s \cdot c, & s^2_r + s^2 \cdot c\\
@@ -162,7 +163,7 @@ Above are the high level instance and witness values known before the protocol s
 #### Verifier
 
 1. Verifier hashes the following to create challenge $c$ as:
-   $$c = \mathrm{Hash}(\mathrm{State}_0, \mathrm{AK}, \mathrm{EK}, \mathrm{at}, \mathrm{ctr}, N, \mathrm{id}, C_{s_i}, C_{\rho_i}, \mathrm{pk}_T, \mathrm{Com}_s, \mathrm{Com}_\rho, C_{\mathrm{BP}_\rho}, C_{\mathrm{BP\_s}\_\rho}, $$
+   $$c = \mathrm{Hash}(\mathrm{State}_0, \mathrm{AK}, \mathrm{EK}, \mathrm{at}, N, \mathrm{id}, C_{s_i}, C_{\rho_i}, \mathrm{pk}_T, \mathrm{Com}_s, \mathrm{Com}_\rho, C_{\mathrm{BP}_\rho}, C_{\mathrm{BP\_s}\_\rho}, $$
    $$T_{\mathrm{state}}, T_{\mathrm{null}}, T_{s-\mathrm{combined}}, T_{\rho-\mathrm{combined}}, T_{\mathrm{enc}_i}, T_{\mathrm{chunks}_i}, T_{\mathrm{BP}_\rho}, T_{\mathrm{BP\_s}\_\rho}, T_{\mathrm{pk}}, T_{\mathrm{EK}})$$
 2. Enforces constraints in Bulletproof for Poseidon2 for $\rho$ generation, and multiplications $\rho^2 = \rho \cdot \rho$ and $s^2 = s \cdot s$
 3. Enforces constraints in Bulletproof for $2 \cdot \mathrm{NC}$ range proofs, $\mathrm{NC}$ for each of $s$ and $\rho$ chunks.