Abstract

Support ECDSA and Schnorr signatures over the SECP256k1 curve in Plutus Core;specifically, allow validation of such signatures as builtins.These builtins work overBuiltinByteStrings.

Motivation: why is this CIP necessary?

Signature schemes based on the SECP256k1 curve are common in the blockchainindustry; a notable user of these is Bitcoin. Supporting signature schemes whichare used in other parts of the industry provides an interoperability benefit: wecan verify signatures produced by other systems as they are today, withoutrequiring other people to produce signatures specifically for us. This not onlyprovides us with improved interoperability with systems based on Bitcoin, butalso compatibility with other interoperability systems, such as Wanchain andRenbridge, which use SECP256k1 signatures for verification. Lastly, if we canverify Schnorr signatures, we can also verify Schnorr-compatible multi orthreshold signatures, such asMuSig2 orFrost.

Specification

Two new builtin functions would be provided:

• A verification function for ECDSA signatures using the SECP256k1 curve; and
• A verification function for Schnorr signatures using the SECP256k1 curve.

These would be based onsecp256k1,a reference implementation of both kinds of signature scheme in C. Thisimplementation would be called from Haskell using direct bindings to C. Thesebindings would be defined incardano-base, using its existingDSIGNinterface, with new builtins in Plutus Core on the basis of theDSIGNinterface for both schemes.

The builtins would be costed as follows: ECDSA signature verification hasconstant cost, as the message, verification key and signature are allfixed-width; Schnorr signature verification is instead linear in the messagelength, as this can be arbitrary, but as the length of the verification key andsignature are constant, the costing will be constant in both.

More specifically, Plutus would gain the following primitive operations:

• verifyEcdsaSecp256k1Signature :: BuiltinByteString -> BuiltinByteString -> BuiltinByteString -> BuiltinBool, for verifying 32-byte message hashes signedusing the ECDSA signature scheme on the SECP256k1 curve; and
• verifySchnorrSecp256k1Signature :: BuiltinByteString -> BuiltinByteString -> BuiltinByteString -> BuiltinBool, for verifying arbitrary binary messagessigned using the Schnorr signature scheme on the SECP256k1 curve.

Both functions take parameters of a specific part of the signature scheme, eventhough they are all encoded asBuiltinByteStrings. In order, for bothfunctions, these are:

1. A verification key;
2. An input to verify (either the message itself, or a hash);
3. A signature.

The two different schemes handle deserialization internally: specifically, thereis a distinction made between 'external' representations, which are expected asarguments, and 'internal' representations, used only by the implementationsthemselves. This creates different expecations for each argument for both ofthese schemes; we describe these below.

For theECDSA signaturescheme,the requirements are as follows. Note that these differ from the serializationused by Bitcoin, as the serialisation of signatures uses DER-encoding, whichresult in variable size signatures up to 72 bytes (instead of the 64 byte encodingwe describe in this document).

• The verification key must correspond to the(x, y) coordinates of a pointon the SECP256k1 curve, wherex, y are unsigned integers in big-endian form.
• The verification key must correspond to a result produced bysecp256k1_ec_pubkey_serialize,when given a length argument of 33, and theSECP256K1_EC_COMPRESSED flag.This implies all of the following:
  • The verification key is 33 bytes long.
  • The first byte corresponds to the parity of they coordinate; this is0x02 ify is even, and0x03 otherwise.
  • The remaining 32 bytes are the bytes of thex coordinate.
• The input to verify must be a 32-byte hash of the message to be checked. Weassume that the caller ofverifyEcdsaSecp256k1Signature receives themessage and hashes it, rather than accepting a hash directly: doing socan be dangerous.Typically, the hashing function used would be SHA256; however, this is notrequired, as only the length is checked.
• The signature must correspond to two unsigned integers in big-endian form;henceforthr ands.
• The signature must correspond to a result produced bysecp256k1_ecdsa_serialize_compact.This implies all of the following:
  • The signature is 64 bytes long.
  • The first 32 bytes are the bytes ofr.
  • The last 32 bytes are the bytes ofs.

      ┏━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━┓    ┃ r <32 bytes> │ s <32 bytes>  ┃    ┗━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━┛    <--------- signature ---------->

For the Schnorr signature scheme, we have the following requirements, asdescribed in the requirements forBIP-340:

• The verification key must correspond to the(x, y) coordinates of a pointon the SECP256k1 curve, wherex, y are unsigned integers in big-endian form.
• The verification key must correspond to a result produced bysecp256k1_xonly_pubkey_serialize.This implies all of the following:
  • The verification key is 32 bytes long.
  • The bytes of the signature correspond to thex coordinate.
• The input to verify is the message to be checked; this can be of any length,and can contain any bytes in any position.
• The signature must correspond to a pointR on the SECP256k1 curve, and anunsigned integers in big-endian form.
• The signature must follow the BIP-340 standard for encoding. This implies allof the following:
  • The signature is 64 bytes long.
  • The first 32 bytes are the bytes of thex coordinate ofR, as abig-endian unsigned integer.
  • The last 32 bytes are the bytes ofs.

      ┏━━━━━━━━━━━━━━┯━━━━━━━━━━━━━━━┓    ┃ R <32 bytes> │ s <32 bytes>  ┃    ┗━━━━━━━━━━━━━━┷━━━━━━━━━━━━━━━┛    <--------- signature ---------->

The builtin operations will error with a descriptive message if given inputsthat don't correspond to the constraints above, returnFalse if the signaturefails to verify the input given the key, andTrue otherwise.

Rationale: how does this CIP achieve its goals?

We consider the implementation trustworthy:secp256k1 is the referenceimplementation for both signature schemes, and is already being used inproduction by Bitcoin. Specifically, ECDSA signatures over the SECP256k1 curvewere used by Bitcoin before Taproot, while Schnorr signatures over the samecurve have been used since Taproot.

An alternative approach could be to provide low-level primitives, which wouldallow any signature scheme (not just the ones under consideration here) to beimplemented by whoever needs them. While this approach is certainly moreflexible, it has two significant drawbacks:

• It requires 'rolling your own crypto', rather than re-using existingimplementations. This has been shown historically to be a bad idea;furthermore, if existing implementations have undergone review and audit, anysuch re-implementations would give us the same assurances as those that havebeen reviewed and audited.
• It would be significantly costlier, as the computation would happen in PlutusCore. Given the significant on-chain size restrictions, this would likely betoo costly for general use: many such schemes rely on large precomputedtables, for example, which are totally unviable on-chain.

It may be possible that some set of primitive can avoid both of these issues(for example, the suggestions inthisCIP); in the meantime,providing direct support for commonly-used schemes such as these is worthwhile.

Backward Compatibility

At the Plutus Core level, implementing this proposal induces nobackwards-incompatibility: the proposed new primitives do not break any existingfunctionality or affect any other builtins. Likewise, at levels above PlutusCore (such asPlutusTx), no existing functionality should be affected.

On-chain, this requires a hard fork.

Path to Active

Acceptance Criteria

• Include tests of functionality with implementation.
• Satisfaction of CIP-0035 requirements (Additions to the Plutus Core Builtins) including costing.
• Inclusion of SECP in Plutus core (as of Valentine hard fork).

Implementation Plan

• Provide an implementation: by MLabs,merged into Plutus.

Copyright

This CIP is licensed underApache-2.0.