Support ECDSA(secp256k1) keys

[tinker-michaelj]

Overview

At present, the only kind of cryptographic public key that may appear in a Hedera key structure is an Ed25519 public key. It follows that users can only secure their transactions using Ed25519 signatures.

Some users, however, might prefer to use ECDSA(secp256k1) keys as on the Bitcoin network.

This idea is to enable support for ECDSA(secp256k1) by,

1. Extending the Hedera API protobufs with new fields for ECDSA(secp256k1) keys and signatures.
2. Clearly documenting how users would populate these new protobuf fields.
3. Updating the node software to support ECDSA(secp256k1) keys and signatures wherever their Ed25519 equivalents are currently supported.

Protobuf changes

Only two protobuf changes are required. To the Key message type, we need to extend the oneof key with a new choice:

message Key {
    oneof key {
        ...
        /**
         * Compressed ECDSA(secp256k1) public key bytes
         */
        bytes ECDSA_secp256k1 = 7;

To the SignaturePair message type, we need to extend the oneof signature with a new choice:

message SignaturePair {
    ...
    oneof signature {
        ...
        /**
         * ECDSA(secp256k1) signature
         */
        bytes ECDSA_secp256k1 = 6;

Protobuf field usage

When a user is creating or updating a Hedera key structure to include a ECDSA(secp256k1) public key, they should set the bytes of the Key.ECDSA_secp256k1 field to the compressed form of the public key. (That is, the first byte should be 0x02 if the y-coordinate of the key is even, and 0x03 if the y-coordinate is odd; and the following 32 bytes should be the x-coordinate as an unsigned 256-bit integer.)

For example, if the user's key pair has,

  public x coord: 30215706507791629899960430517232235275000002464034938000648205570353843228303
  public y coord: 14152164375773628889345997156717932001811675396914245134380969244261391953841

Then the hex-encoded bytes of the Key.ECDSA_secp256k1 field should be,

0x0342cd7bdc42bb0bbf9cd3c31479521ebbe7c729251e21cf2148bcd8d43c4d4e8f

While if the key pair has,

  public x coord: 82320372298163969708040656530484673130018359270243775662302157667426266882648
  public y coord: 16530900404587179989301633022594415830923307118357223838237239310583951083392

Then the hex-encoded bytes of the Key.ECDSA_secp256k1 field should be,

02b5ffadf88d625cd9074fa01e5280b773a60ed2de55b0d6f94460c0b5a001a258

When a user is providing an ECDSA(secp256k1) signature in a SignaturePair. ECDSA_secp256k1 field, it should be the full result of signing the SignedTransaction.bodyBytes from the top-level Transaction with the relevant ECDSA(secp256k1) private key.

Node software enhancement

The implementation is relatively straightforward, with the main possible concern being a performance impact relative to verification of Ed25519 signatures.

If this impact proves significant, it would be necessary to throttle transactions with ECDSA(secp256k1) signatures to a somewhat lower TPS than for Ed25519.

[arslan-raza-143]

Ed25519