-
Notifications
You must be signed in to change notification settings - Fork 479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support SECP256K signature verification #4233
Comments
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:
Are there any others? |
https://github.com/bitcoin-core/secp256k1 - Bitcoin's implementation https://hackage.haskell.org/package/secp256k1 - another Haskell binding i quickly found |
If you can enumerate your standards, happy to dig deeper on this. |
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. |
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 |
https://github.com/haskoin/secp256k1-haskell seems to be of OK quality. |
@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. |
@michaelpj Now that the PR to |
New builtin. It's unfortunate that we gave |
Can't you rename it to that, and make the old name in PlutusTx.Builtins a deprecated alias of that? |
That won't change the name in Plutus Core. We can potentially do something like that at the library level. |
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. |
@michaelpj I'd be happy to collaborate on a retroactive CIP. How would you like to do this? |
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. |
@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. |
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
The text was updated successfully, but these errors were encountered: