# Notes on Namada's airdrop protocol

## Authentication issue

In Zcash Sapling (and Orchard), spend authority is demonstrated by signing with a randomized key that is linked to the proof via the randomization factor $\alpha$. The proposed airdrop protocol does not do this, and so does not directly show that the claimant holds the relevant Sapling notes.

In the case of Sapling, the holder of spend authority also knows a "proof authorizing key" $\mathsf{nsk}$. Under normal circumstances this would *only* be known by a holder of spend authority, but the separation between the actual spending key $\mathsf{ask}$ and the proof authorizing key $\mathsf{nsk}$ was intentional: it was designed to support use cases in which a more trusted device would hold $\mathsf{ask}$, with $\mathsf{nsk}$ being held by a more computationally powerful but less trusted device.

> Although there was little deployment of this facility of the protocol, some prototypes were built (one by @str4d allowing proof delegation, and one demonstrated at Zcon3 for the Trezor hardware wallet). It is still intended to deploy hardware wallets using it in future.

The effect of not authenticating by signature would be that for shielded funds held in a hardware wallet using this feature, the airdrop would be claimable *without* the user authorizing it on the hardware wallet, instead only requiring the keys from the host computer (or the party to which proofs are delegated).

> We also considered whether there could also have been a security problem due to the way "extended child full viewing keys" [are derived from](https://zips.z.cash/zip-0032#deriving-a-child-extended-full-viewing-key) "extended parent full viewing keys" in [ZIP 32](https://zips.z.cash/zip-0032). We were concerned because the $I_{\mathsf{nsk}}$ value that relates parent and child keys can be computed just from the "extended parent *full viewing key*", not the "extended parent *spending key*". However, we've analysed this issue and determined that there is no such security problem when using the claim protocol with Sapling and ZIP 32: in particular, it is not possible to obtain $\mathsf{nsk}$ of the child key without having it for the parent key.

### Inapplicability to Orchard

For Orchard, the key derivation was simplified so that there is no $\mathsf{nsk}$. This means that an Orchard counterpart of Namada's protocol would be insecure, because it does not bind to the spending key, and therefore a full viewing key would be sufficient information to make a claim. That would be a flaw because it is intended to be possible to give a full viewing key to an untrusted auditor. This issue is not fatal to the protocol's use with Sapling, but it would be preferable for the airdrop functionality (which is also potentially useful for other applications requiring proof of holding funds) to be applicable to both Sapling and Orchard.

## Trust model issues

The airdrop protocol depends on sending the secret value $\mathsf{rcv^{Sapling}}$ for each note to the Namada wallet. If this value is intercepted, the intercepting party could claim the airdrop.

Consider the situation of a Zcash user who is using Namada for the first time in order to claim their airdrop. They trust their Zcash wallet, but they might be vulnerable to social engineering attacks that result in them sending $\mathsf{rcv^{Sapling}}$ via a third-party "helper" who is actually trying to steal the airdropped funds.

If the Zcash wallet could display the Namada destination address and create a claim that is only valid for that address, then such users would be much less vulnerable. They are assumed to already have a Zcash wallet which will show them the destination address via UI that they trust. The circuit on the Namada chain would enforce that the claim can only go to the destination address that is associated with it, i.e. the one that was displayed by the Zcash wallet.

If this is considered a useful improvement, we recommend one of two approaches to implement it:

1. Require the Zcash wallet to create a signature specific to a Namada address. (This could also address the claim authentication issues in the previous sections, by doing claim authentication more similarly to spend authentication.)
2. Tie the Spend proof to a Namada address by making $\mathsf{rcv}$ a (randomized) commitment to the Namada address. This works because $\mathsf{cv}$ is a binding commitment to $\mathsf{v}$ even if $\mathsf{rcv}$ is known. (It is required to check that $\mathsf{rcv}$ is canonically encoded on the scalar field.)

Using either of these approaches is inherently safer than the original protocol, because it's less dependent for claim authentication on the secure channel used to transfer $\mathsf{rcv}$.

## Wallet support issues

The protocol requires every Zcash wallet for which the airdrop can be claimed to support it.
* We have no intention of implementing new features of this complexity in zcashd. But, recovering from seed in a `zcash_client_backend`-based wallet would be sufficient if the latter supported the claim protocol.
* The Zcash wallet does not need the nullifier set, but it needs the anchor at the airdrop height and enough information to reconstruct witnesses at that height. This probably requires rescanning.

ECC does not have the capacity to implement the Zcash side of the claim protocol given other commitments. Namada would have to implement it for `zcash_client_backend` in a way that satisfies ECC's review policy for robustness and security. It would be preferable for this to be done in a way that could be generalized beyond this particular airdrop.

## Minor limitations

The number of Sapling zatoshi needs to be a multiple of $V_{Sapling}$.

## Cofactor usage

We have not analysed the use of the cofactor $\mathsf{h}_{\mathbb{J}}$ in the statement on the Namada side. In general cofactors introduce difficult-to-analyse hazards in cryptographic protocols.

## Privacy considerations for the Zcash wallet

Creating a spend proof for a note reveals its nullifier (which, in this protocol, becomes effectively public as part of the airdrop's nullifier set). If is done naively then this would leak information that would link Zcash transactions.

To mitigate this privacy leak, the Zcash wallet should inspect its past transactions, to determine the groupings for which the notes that were unspent at the airdrop height have been subsequently spent, i.e.:

* $k$ sets of notes that remain unspent, split so that both Zcash and Namada transaction size constraints are met;
* $n$ sets of notes, each previously spent within a single Zcash transaction.

There will create $n+k$ Namada claim transactions, as well as $k$ Zcash transactions that explicitly spend all remaining unspent notes on the Zcash side (so that they don't get spent in a different way allowing linkage across future transactions).

At the end of the process, none of the notes in the airdrop set remain unspent.

The fee required to do this on the Zcash side is the fee required to spend all the unspent notes.

## Nitpicks

* "the nullifier set associated with NoteCommit^Sapling at [the airdrop height]" should be "the nullifier set associated with the Sapling treestate at [the airdrop height]".
* The information sent for each note needs to include the corresponding value $\mathsf{v^{Sapling}}$.
* In the [Within the zcash wallet](https://github.com/anoma/namada-shielded-airdrop/blob/main/PROTOCOL.md#within-the-zcash-wallet) section, $\mathsf{vb^{Sapling}}$ should be $\mathcal{V}^{\mathsf{Sapling}}$.
* "the MASP VP would have implemented inside a Sapling verifier" => "a MASP VP corresponding to the Sapling Spend proof needs to be used".

## Open questions

* What if the Namada transactions are too large?
* Will the claims on the Namada side be in the same transaction, or in one transaction per claimed Sapling note?
* Is the airdrop time-limited?