# Muh Privacy: Separating public and private inputs
We shall address how our equation changes to allow for both public and private inputs.
Let’s recap; the prover calculates the following EC points:
And the verifier will calculate pairing( **`α[G1]`**, **`β[G2]`**) and the equality:
Let us split our previously used witness into public and private inputs:
* Here we assume that the public inputs are 1 and out; and the rest are private inputs.
* Public inputs are handled by the verifier
* Private inputs are handled by the prover
As much as we are splitting the witness vector up based on privacy, this only impacts the construction of `[C]`. \[A] and \[B] remain unchanged.
* \[C] is computed over private inputs by the prover
* \[C] is computed over public inputs by the verifier
This means that the prove computes a fragment of \[C] and passes it to the verifier, which then computes the remaining public fragment, obtaining the whole piece; then proceeding to verify the proof.
### **Splitting `[C]`**
*Note that while we use polynomial expression (W\.a and so forth), it should be synonymous with their respective EC point forms.*
* For the verifier, the summation symbol starts with 0 and ends with 1, indicating the 1st and 2nd term of the witness vector: $a\_i: a\_0, \space a\_1$
* $$a\_0$$: `1`
* $$a\_1$$: `out`
* Notice that the prover is responsible for calculating `[HT]`, and the verifier handles `[αβ]`
* Given the new breakdown of `[C]`, the verifier key will have to accommodate the necessary EC data. We will address what the final proving and verifier key are at the end.
#### Alternative visual
### Preventing forgeries due to splitting \[C] **with γ and δ**
There is nothing preventing a malicious prover from using public inputs to, uhh, somehow magically create a valid forged proof.
To negate this attack vector, we introduce another set of greek alphabets: γ and δ.
* The verifier fragment of \[C] is divided by **γ**
* The prover fragment of \[C] is divided by **δ**
* These values are randomly sampled during the trusted phase setup
**What this looks like:**
### Verification with γ and δ
$$
e(\[A]\_1, \[B]*2) \stackrel{?}{=} e(\[C*{private}]\_1, \[γ]*2) + e(\[C*{public}]\_1, \[δ]\_2) + e(\[α]\_1, \[β]\_2)
$$
* Prover generates EC points: \[A], \[B], \[C\_private]
* Verifier generates EC points: \[C\_public]
* Verifier calculates the 4 bilinear mappings as seen above, and checks for equality
* The following values are randomly sampled during the trusted setup phase:
* **γ**, **δ, α, β and τ**
* are communicated as EC points of different groups to the verifier to obfuscate their values.
### Trusted Setup
### Last Problem: Guessability
If the range of values over witness vector variables can take are very small and therefore easily guessable; e.g. a binary variable that only be either 1 or 0.
In such a situation, an attacker can iterate through a list of guesses of proofs to generate a legitimate one.
**Solution**
* The solution is to introduce more greek alphabets - for salting/random shifting, of course.
* In this case, we will introduce **`r`** and **`s`**.
* r & s are introduced in the proving phase. (Not trusted setup)
* Prover randomly samples 2 field elements.
* Both **`[A]`** and **`[B]`** are shifted with the introduction of **`r`** and **`s`**; similar to the introduction of alpha and beta
* Prover needs to use one of the EC points within the proving key to raise both `r` and `s` into EC points themselves; hence the use of **`[δ]`**
Obviously with the introduction of new variables we need to balance the equality. Though the question is how:
* By this point it should be evident to the reader how `sU` and `rV` map to `s[A]` and `r[B]`.
* There might be some initial confusion as to why the last term is `- rs[δ]` and not perhaps `+ rs[δ]`
* **This is why:**
* **`sU`** and **`rV`** are actually representative of the old **`[A]`** and **`[B]`** points; pre-shifting with **`r`** and **`s`**.
* Whereas **`s[A]`** and **`r[B`**`]` introduced as balancing terms to the RHS, are reflective of the new **`[A]`** and **`[B]`** points; inclusive of the shifting caused by **`r`** and **`s`**.
* Instead of using the “old” points. we use the new points and negate the extra **`rs`** term.
This means we now need a **`[B]`** and **`[δ]`** in **G1**, as part of balancing **\[C]** - amongst other additions to the trusted setup phase. We will list the final variables in the next section.
