Support SECP256K signature verification

[Benjmhart]

Describe the feature you'd like

In order to support decentralized bridge technologies for the ERC20 token converter project and other bridging projects, it is clear that the SECP256k signature scheme is needed - likely as a low-level call from the plutus interpreter directly

Describe alternatives you've considered

We've done some initial research on this at MLabs, and one of our researchers pointed to this existing implementation:
https://github.com/Chia-Network/bls-signatures

which has FFI bindings in Haskell:
https://github.com/hexresearch/hschain/tree/master/bls-signatures

[michaelpj]

The main thing we need is a high-quality, trustworthy implementation that we're comfortable linking into the Cardano node stack.

The linked implementation doesn't fill me with confidence:

NOTE: THIS LIBRARY IS NOT YET FORMALLY REVIEWED FOR SECURITY

Are there any others?

[Benjmhart]

https://github.com/bitcoin-core/secp256k1 - Bitcoin's implementation

https://hackage.haskell.org/package/secp256k1 - another Haskell binding i quickly found

[Benjmhart]

If you can enumerate your standards, happy to dig deeper on this.

[michaelpj]

It would also be helpful to explain some of the usecases a bit more clearly, also so we know we're actually providing the right primitives.

[michaelpj]

From a brief internal consultation the bitcoin library is probably fine. I don't know whether the Haskell binding is good quality, that would need to be reviewed too.

I suspect the best next step would be a PR of an implementation of the relevant bits in cardano-crypto-class, probably it should fit into DSIGN if you're looking for the signature verification part: https://github.com/input-output-hk/cardano-base/tree/master/cardano-crypto-class/src/Cardano/Crypto/DSIGN

[L-as]

https://github.com/haskoin/secp256k1-haskell seems to be of OK quality.

[Benjmhart]

@michaelpj - this actually comes from the ERC20 token converter team, who hopes to use the technology of Wanchain or similar to bridge tokens onto cardano in a decentralized fashion.

These technologies break up the private key among multiple validators, so that only by working in concert, can they properly sign a transaction.

Since the default transaction-level signature is incompatible, they wish to provide the signature in Datum to be validated at the smart contract level.

[kozross]

@michaelpj Now that the PR to cardano-base is done (and nearly merged), what should be the next step? There's already a VerifySignature builtin, but it's hardcoded to a specific algorithm. Should I add another builtin, or generalize the existing one?

[michaelpj]

New builtin. It's unfortunate that we gave verifySignature such a generic name, it should really have been verifyEd25519Signature. The challenge will be costing it, but for now I think just leave the costing function as mempty.

[L-as]

Can't you rename it to that, and make the old name in PlutusTx.Builtins a deprecated alias of that?

[michaelpj]

That won't change the name in Plutus Core. We can potentially do something like that at the library level.

[michaelpj]

BTW: I'm not going to insist that we follow cardano-foundation/CIPs#215 before getting this merged (unless you want to!), but I would be keen to collaborate on a retroactive CIP. Partly to enshrine the motivation etc., and partly just to put more examples through the process.

[kozross]

@michaelpj I'd be happy to collaborate on a retroactive CIP. How would you like to do this?

[michaelpj]

I'll share a google doc with you. It's not the best editor for this, but it's good for collaboration and we can port it to markdown later.

[KowsarAtz]

@michaelpj There is a related issue (#4575) that I would appreciate it if you take a look at it. We need to recover a public key from a signature (produced with an ethereum address) and a message hash. What we need is basically the exact implementation of ethereum ecrecover function which can be implemented using functions provided by libsecp256k1.