design: Shielded outputs

[msbrogli]

Rendered

[obiyankenobi]

but the full spend pubkey is not recoverable from the address alone — it must be obtained from the blockchain (from a prior spend) or out-of-band.

Who must obtain it? The receiver already has it and the sender does not need it, correct?

[msbrogli]

The sender. But the previous text was misleading and was updated. Let me explain here: For shielded outputs, the compact address is enough and nothing has to be recovered by the sender. But it imposes a limitation for silent payments.

[obiyankenobi]

or include a transparent output

In this case, won't we still know the amount in the shielded output? In other words, won't we require still 2 shielded outputs?

[obiyankenobi]

Also, this rule will be enforced on the wallet, correct? From the protocol side, should be possible to do it even if it "leaks" information.

[msbrogli]

Indeed. I added this rule to open the discussion whether the protocol should require at least two shielded outputs or not.

When there are two or more shielded outputs and all inputs are transparent, observers can determine the total value of the outputs, but not how that value is distributed among them.

If there's at least one shielded input, observers can only infer that sum(outputs) > sum(transparent_inputs).

[obiyankenobi]

Got it. I believe we should not enforce it at the protocol level. We should probably make it standard in the wallet library, though.

[obiyankenobi]

How do you generate it? Do you take some info from the output to make it unique?

[msbrogli]

No, you generate a random number e and multiply by G.

[LFRezende]

Overall a really fine document, with only minor confusions and mistakes and/or just minor stuff that needs clarification. I think that after this first batch of reviews should already be approvable.

[LFRezende]

Not wrong, but I think you're hinting far too early the concept of shielded minting/melting, and not necessarily explaining why we need a shielded issuancer to cover for transparent minting/melting.

Maybe something on the lines of "while transparency for minting/melting operations is fundamental to probe the network's balance of token supplies, the transparency of these operations reveals the transaction that issued the supply change, exposing the identity of the issuer."

[LFRezende]

It is increasingly clear we will not go to mainnet with Borromean, both for cost optimizations and to parallelize verifications and proofs. So we need to change this section to include Bulletproofs.

| Tier | Hides Amount | Hides Token | Proof Overhead | Use Case |
|------|:---:|:---:|---|---|
| `AmountShieldedOutput` | Yes | No | Range proof (~ $675 + 64\cdot log_2 (n)$ bytes) | Hide salary amounts while token type is public |
| `FullShieldedOutput` | Yes | Yes | Range proof (same as above) + surjection proof (variable bytes) | Full privacy for multi-token transactions |

Additionally, the range of the proof is not

$[1, 2^40]$ 

But:

$[1, 2^(64 + \ceil{\frac{D}{log_10 2}})]$ 

Where D is the decimals we intend to add in the future as precision.

For simplicity, we can say for now [1, 2^k], where k is the number of range proof bits we intend to use, where typically k == 64.

Final paragraph rewritten:

| Tier | Hides Amount | Hides Token | Proof Overhead | Use Case |
|------|:---:|:---:|---|---|
| `AmountShieldedOutput` | Yes | No | Range proof (~ $675 + 64\cdot log_2 (n)$ bytes) | Hide salary amounts while token type is public |
| `FullShieldedOutput` | Yes | Yes | Range proof (same as above) + surjection proof (variable bytes) | Full privacy for multi-token transactions |

Both tiers use **Pedersen commitments** for amounts and **Bulletproof range proofs** to guarantee amounts are non-negative (specifically in `[1, 2^k)`), where k is the number of range proof bits we intend to use, typically `k == 64`. `FullShieldedOutput` additionally uses **blinded asset tags** and **asset surjection proofs** to hide and validate the token type.

[LFRezende]

Opinion: The shielding section basically assumes profficiency with pedersen commitments, blinding factors and such.

Adding a "preliminaries" subsection here to introduce the basic concepts and hooks we'll work with, such as pedersen commitments, hash-to-point and such, could do massive work to easen the blow to newcomers.

No need to go too technical, just introducing and explaining what it does is enough.

[LFRezende]

Scratch that. He does know the amount if he can sum. The whole point is unshielding. If we wished him not to know, we'd have two shielded inputs.

[LFRezende]

I think we already have this implemented? Or if not, I think we create pedersen commitments with zero value and just the excess blinding factor.

[LFRezende]

I may need to review the docs on Generator::new_blinded() to be sure, but the tag usually has a counter, like this:

tag = SHA256("Hathor_AssetTag_v1" || token_uid_32B || k)
k = 0, 1, 2, ...

H_token is a hash-to-point procedure, so the hash MAY lie on the curve or not (~50% chance for secp256k1).

In case it doesn't, we need to increase k and try again. The probability of it not lieing on a curve is 2**(-attemps) so eventually it will fall.

I pointed out in a previous repo review that the lib we used did not do this, but they seemed to use a different procedure. Nevertheless, it is worth flagging it out.

[LFRezende]

This holds only for ``AmountHidden` shielded outputs.

For FullShielded shielded outputs, C = v*A + r_value*G, where A = H + r_asset*G is the blinded asset tag. In amount only, r_asset = 0.

We should have a small section disclaiming it, and I advise for us to handle mentally all Pedersen Commitments as C == v*A + r*G, to avoid mistakes in the future.

[LFRezende]

This line depends on the choice we go with for the addresses. Some scripts may change (we may abandon P2PKH).

[LFRezende]

Indeed it is fine to leave a 1% HTR deposit rate, as mint/melt amounts are public.

[LFRezende]

Great comment. I like it.