AZIP-10 Introducing new public keys to the preimage of an address

[IlyasRidhuan]

The tagging key is currently unused in the protocol, there is a draft AZIP-10 that is looking to re-purpose the tagging keys to be kind of enshrined signing keypair that users can leverage outside of the authwit scheme.

At some point in the review, @iAmMichaelConnor wrote this, which summarises into the following points

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

Let's discuss!

[iAmMichaelConnor]

Continuing a discussion from #22

Maybe a stupid question, but could we also leverage the existing TPK for note discovery in case the sender is unknown via scanning?
I know this is inefficient, but we could leverage TPK for such hopefuly infrequent cases, making scanning not a huge deal?

Yes, quite possibly. It was put there for such brute-force scanning reasons.

Are there concrete uses to an enshrined signing key that aren't covered by authorization?

@nventuro is building a handshaking registry for "constrained delivery", which involves verifying a signature from a recipient. It's more efficient if this signature verification happens within the registry contract, rather than making an authwit call to the recipient's address to verify the signature.
Having said that -- and as I touch on in my big suggested comment comment above, which has been incorporated into the AZIP -- the act of establishing a handshake might be rare enough that having an extra kernel iteration to make an authwit call could be acceptable. Wdyt, Nico?

My favourite direction for this AZIP is now:

• Keep the Tpk
• Introduce a "Not-for-tx-auth Message Signing Key" -- for signing arbitrary messages, but not for authorising transactions.
• Introduce a "Fallback EoA Key" -- for proving ownership in cases where an account contract cannot be trusted.

So two new public keys added to the preimage of an address.

People have talked about having a place for custom keys to be added to the preimage of an address. Membership witnesses of those keys would have to be a constant number of gates, so the obvious choice would be to store a merkle root within the keys_hash of an address; call it custom_keys_root. We could start with a tree of, say, 16 leaves (4 high) into which arbitrary public keys could be stored as leaves, hashed with an identifier for the nature of the public key stored there.
I haven't seen use cases for custom keys other than the new "Not-for-tx-auth Message Signing Key" and "Fallback EoA Key" being proposed.