AZIP-10: Rename tpk

[IlyasRidhuan]

No description provided.

[iAmMichaelConnor]

I added big sections to the Rationale. I thought as I wrote, and ended up tentatively concluding:

• Maybe the Tpk could still be useful (under-explored)
• Maybe an additional "migration pk" is needed, in addition to a new signing key
• Maybe authwits can be used instead of a signing key.

Mild panic intensifies.

[iAmMichaelConnor]

Suggested change

	### What is the tagging key for?
	The tagging key is a 3-year-old concept that was intended to help a recipient more quickly brute-force-identify which logs are pertinent to them. The idea is explained [here](https://ethereum-magicians.org/t/erc-5564-stealth-addresses/10614/4). But it quickly fell out of favour:
	- It was only slightly more computationally efficient than the approach taken in the finalised Stealth Addresses EIP, and it was actually less efficient to download. This bandwidth efficiency is the primary bottleneck to brute-forcing, so the tagging public key idea was strictly worse.
	- In most cases, it is assumed that a sender and recipient can interact before any Aztec transactions, so they can pre-establish a shared secret, which removes the need to brute-force, and hence reduces the need for any brute-forcing optimisations at the protocol level.
	- (Note: some use cases will _still_ require non-interactivity: that the sender must convey a shared secret to the recipient via the blockchain without any prior interactions. In such cases, brute-forcing of an initial shared secret will still be needed, but the tagging public key would still not be helpful in improving such brute-forcing).
	Some mistake the intented usage of the tagging keypair as the keypair that should be used to establish a tagging shared secret: that was never the case. The convention is to use the ivsk for establishing shared secrets for both encryption/decryption and for tagging.
	It could be argued that if we were to use separate keypairs for tagging and for encryption, then it would enable finer control over the "viewability" of a user's activity. The ivsk could be shared with a trusted 3rd party to enable them to decrypt all incoming notes, messages, and events; and a distinct "tagging secret key" could be shared with a trusted 3rd party to give them a much more restricted ability to only determine which onchain logs are pertinent to the user, but not to decrypt those logs. The latter can be summarised as "I can see which logs are for you, but I can't see what they contain". This would enable the user to reveal to the 3rd party only select details about the logs with zero-knowledge proofs, whilst preventing the user from omitting any logs.
	It's an interesting idea that came up when the keys scheme was being designed. It was preferred to have a recipient's address be the only piece of information that a sender needs in order to transact with them. The address is technically a public key, whose corresponding secret key is `ivsk + pre_address`. So to preserve the aim of only needing a user's address to transact, the `ivsk` naturally becomes the only secret key that should be used to establish shared secrets for both encryption and tagging.
	This elegant requirement is slowly unravelling, however. Several use cases have been encountered where simply providing a sender with a recipient's address is insufficient, and actually items from the preimage of the address are needed:
	- Patterns whereby a user A needs to execute an authwit function of another user B's account contract.
	- In this case, the underlying private function ACIR -- and hence most of the preimage of the user B's address -- needs to be provided to the executor of the function (user A) so that they may execute the function, and because the kernels require this information.
	- (There's outstanding research which could explore whether B could generate a _proof_ of the authwit function and associated kernel iteration and provide that to A. Currently, due to folding, B would leak witness data to A. Besides, requiring an entire witness from B still violates the unravelling aim of only requiring B's address).
	- Patterns relating to the signing key, as introduced by this AZIP: if a user A wants to verify a signature from user B -- signed using B's signing secret key -- then A needs to be given the membership witness to prove existence of B's signing public key within B's address.
	- Key rotation ideas would require a sender to read extra information (beyond a recipient's address) from a registry.
	- Post-quantum keys (a future area of research) will undoubtedly require large amounts of data to be transferred between users. In this light, the notion of only sharing a small address between users is not sustainable.
	Ok, so if we're beginning to realise that "only sharing a recipient's address" is not sustainable, then maybe we should entertain the continued usefulness of a separate tagging keypair. Let's explore common ways in which a shared secret can be established:
	| Approach | Derivation |
	|---|---|
	| static-static | $S = \text{sk}_A \cdot \text{Pk}_B = \text{sk}_B \cdot \text{Pk}_A |
	| ephemeral-static | $S = \text{ephemeral_sk} \cdot \text{Pk}_B = \text{sk}_B \cdot \text{Ephemeral_pk} |
	| ephemeral-ephemeral | $S = \text{ephemeral_sk}_A \cdot \text{Ephemeral_pk}_B = \text{ephemeral_sk}_B \cdot \text{Ephemeral_pk}_A |
	What happens if we give a trusted 3rd party access to the `ivsk` or `tsk` under these different scenarios. Can the trusted 3rd party actually derive all of a user's shared secrets and ultimately learn all plaintexts (for `ivsk`) / all pertinent logs (for `tsk`), solely given access to `ivsk` / `tsk` and public blockchain data?
	The answer is no.
	- In the case of static-static:
	- Not all addresses are publicly known, so any shared secrets $S$ that are established offchain with non-public addresses cannot be derived by a trusted 3rd party.
	- In the case of ephemeral-static:
	- Only if the $\text{Ephemeral_pk}$ is broadcast to the public bulletin board (Aztec logs) will the 3rd party be able to derive the shared secret. Only use cases which adopt "non-interactive, constrained delivery" technically need to satisfy this. For all other use cases, there would not be sufficient public information for the trusted 3rd party to be able to derive all shared secrets -- be they tagging shared secets or encryption shared secrets.
	- In the case of ephemeral-ephemeral:
	- These shared secrets are completely detached from any user's secret keys, so a 3rd party's knowledge of `ivsk` or `tsk` is useless.
	This isn't to say that the notion of "sharing viewing keys with 3rd parties" is dead. It just means that individual app developers who wish to offer this feature to users -- of guaranteeing that the 3rd party can see all pertinent information without omissions -- will need to think very carefully about how to constrain delivery of all relevant shared secret information to that 3rd party.
	There are ways in which the two distinct "viewability" features -- of decrypting and of only being able to identify pertinent logs -- can be achieved without a distinct and canonical tagging keypair...
	But, having written this out, perhaps before we remove the Tpk, we should explore "viewability" patterns in more detail. It could be that the Tpk is useful afterall, despite it not being useful for its original intended purpose. **Perhaps this AZIP should simply introduce the `(ssk, spk)` additively, instead of replacing the `(tsk, tpk)`.