more discussion

core/cap-0051.md

@@ -129,6 +129,22 @@ if hashed and truncated similar to how Ethereum addresses are produced. This
 space reduction would lower the read/write resource usages as well as
 transactions size, for an increase in instruction cost.
 
+#### SEC1 Encoding of Public Key
+
+The proposal specifies the public key to be SEC1 encoded. This encoding is
+65-bytes, containing the point coordinates uncompressed, and is the same
+encoding used by the existing `recover_key_ecdsa_secp256k1` function.
+
+Most applications using secp256r1 are likely to produce a 72-byte ASN.1 DER encoded public key, which is convertible.
+
+#### Compact Encoding of Signature
+
+The proposal specifies the signature to be encoded as two 32-bit big endian
+integers. This encoding is 64-bytes and is the same encoding used by the
+existing `recover_key_ecdsa_secp256k1` function.
+
+Most applications using secp256r1 are likely to produce a 70 to 73-byte ASN.1 DER encoded signature, which is convertible.
+
 #### Webauthn / Passkeys
 
 The secp256r1 verify interface is largely motivated by the webauthn use case. Webauthn involves an application registering with a client, that produces a private key, and provides the public key back to the application. The application can then engage the client to sign data that the application can verify using the public key shared earlier.