SECP256k1 support #4368

kozross · 2022-02-01T20:42:02Z

This closes #4233, together with the relevant cardano-base PR. Currently, this PR depends on the MLabs fork of cardano-base; once the linked PR merges, I will amend to work against master again. This shouldn't affect review, as while this depends on functionality from cardano-base, nothing in here is affected by precisely what branch of cardano-base we pull from.

Edit: This is now done.

I've added some property-based tests using Hedgehog to ensure all possible paths are equally covered. Specifically, we check each of the following:

Malformed pubkey
Malformed signature
Malformed message hash
Use of the wrong verification key
Checking the wrong signature for a given message
The happy path (that is, everything works)

As per @kwxm's feedback on my prior work on plutus-tx, I've raised the test count high enough to ensure that fewer than 1 in a 1000 executions fail due to probabilistic coverage failures (a flaw in Hedgehog, and one we can't avoid).

A few concerns remain:

The builtin for SECP256k1 verification is extremely demanding of how its inputs are formatted, but currently, this is left entirely to the user to ensure: all arguments are BuiltinByteStrings. I didn't know if we wanted helpers (in plutus-tx or elsewhere) to make this process less nasty with newtype wrappers and helper functionality, so I haven't added it.
The tests for untyped-plutus-core are far too few in number: almost everything in there should be a property test, but even those which are run 200 tests, which is too few to indicate anything. For a demonstration of why: I found multiple bugs in how I implemented the SECP256k1 builtin only after over a thousand tests, and even then it took several attempts! Furthermore, coverage is not checked at all, which is alarming. The tests I wrote for the SECP256k1 primitive are vulnerable to neither.
As per @michaelpj's suggestion here, the costing function is currently mempty. I don't know how much of an issue this is.

ysangkok · 2022-02-05T05:33:17Z

It's confusing to refer to all of this as "SECP256k1 support" since SECP256k1 is just a curve. Since you are using secp256k1-haskell, it seems you do not support the Schnorr (BIP-340) signatures recently added to Bitcoin. So I suspect that you have in fact added ECDSA signature support using the SECP256k1 curve. Is that correct?

effectfully

The Haskell part looks great to me, apart from PlutusTx.Builtins.Internal.verifySECP256k1Signature, which I think could be better.

Can't comment on the crypto part.

plutus-core/plutus-core.cabal

effectfully · 2022-02-05T06:21:29Z

plutus-core/plutus-core/src/Crypto.hs

+verifySECP256k1Signature
+  :: BS.ByteString -- ^ Public key
+  -> BS.ByteString -- ^ Signature
+  -> BS.ByteString -- ^ Message hash
+  -> Emitter (EvaluationResult Bool)
+verifySECP256k1Signature pk sig msg =
+  case DSIGN.rawDeserialiseVerKeyDSIGN @SECP256k1DSIGN pk of
+    Nothing -> do
+      emitM "SECP256k1: Given invalid signing key."
+      pure EvaluationFailure
+    Just pk' -> case DSIGN.rawDeserialiseSigDSIGN @SECP256k1DSIGN sig of
+      Nothing -> do
+        emitM "SECP256k1: Given invalid signature."
+        pure EvaluationFailure
+      Just sig' -> case SECP.msg msg of
+        Nothing -> do
+          emitM "SECP256k1: Given invalid message hash."
+          pure EvaluationFailure
+        Just msg' -> case DSIGN.verifyDSIGN () pk' msg' sig' of
+          Left _   -> pure . pure $ False
+          Right () -> pure . pure $ True


@kwxm bad news for ya, we have another emitting bulitin.

Is this a problem in some sense I'm not aware of?

@kozross, not a concern for you, just a pain in the ass to describe in the specification.

I think we were really expecting this to be used only in the in the implementation of trace and not in arbitrary builtins, but I suppose it's harmless and it's commendable to give programmers extra feedback with something that it would be easy to get wrong.

I think from the point of specification, I'd inclined to just not mention this in the specification on the basis that the error messages are a detail specific to this particular implementation. Trying to include the details of the logging mechanism in the specification would complicate things quite a bit, so maybe we could say that an implementation of Plutus Core may choose to provide facilities for logging errors as long as they don't have any effect on the semantics of built-in functions; that's not really got anything to do with this PR though.

Off-topic, this makes me wonder if the logging mechanism could be used to do unexpected things in contract code. Could the off-chain part of a contract run some validation code (also off the chain), look at the log files and then branch on the contents to determine the future behaviour of the contract (which you could do even using trace)? That might provide a way to leak more information from validation than the true/false answer that we expect, but would that actually be a problem?

plutus-tx-plugin/plutus-tx-plugin.cabal

plutus-tx/src/PlutusTx/Builtins/Internal.hs

effectfully · 2022-02-05T06:44:12Z

Ah, yeah, it must conflict horribly with my recent refactoring, I'll fix it for you.

…to mlabs-haskell-koz/secp256k1

effectfully · 2022-02-05T08:00:21Z

Ah, yeah, it must conflict horribly with my recent refactoring, I'll fix it for you.

Done (not horribly at all).

Merge `master` into `mlabs-haskell-koz/secp256k1` and fix what got broken

michaelpj · 2022-02-07T11:22:52Z

For some reason it won't let me respond to the existing comments...

I agree that it's harmless to include tracing here. It's interesting that this is the first builtin other than trace that emits things, but probably good.

I'm not worried about specifying the tracing. We deliberately don't specify anything to do with log emitting since it's not observable in the main behaviour of the program.

Could the off-chain part of a contract run some validation code (also off the chain), look at the log files and then branch on the contents to determine the future behaviour of the contract (which you could do even using trace)?

Yes, but you can do whatever you want off-chain. You can run your PLC through a symbolic executor and buy a sandwich iff it returns true on Tuesday 22nd 2024. So I don't think we need to care about that.

kwxm · 2022-02-07T13:46:21Z

I agree that it's harmless to include tracing here. It's interesting that this is the first builtin other than trace that emits things, but probably good.

I suppose there's not much that can go wrong with most of the existing builtins (mostly out of range errors), so there's no need give details when something goes wrong. Maybe we could be more informative with some of the other ones though. I 'll have to benchmark this for costing purposes at some point and while I'm doing that I'll check that the logging isn't adding any overhead. It's highly unlikely that it will be since nothing at all should be happening on chain, but there's no harm checking.

kwxm

Looks good.

kwxm · 2022-02-07T12:43:33Z

plutus-core/plutus-core/src/PlutusCore/Default/Builtins.hs

@@ -786,6 +791,7 @@ instance Flat DefaultFun where
              Sha3_256                 -> 19
              Blake2b_256              -> 20
              VerifySignature          -> 21
+              VerifySECP256k1Signature -> 51


It's a bid odd seeing the results in non-sequential order, but I see the point. We probably don't want to do this too much though, or it'll be hard so spot gaps and duplicates.

In fact, maybe that should go at the end. If someone else wants to add a new builtin they might look at the end of the list and think that 51's the next free tag.

So do you suggest I use the largest number available for VerifySECP256k1Signature instead of 51? There's no specified system of numbering these in the documentation of the module.

No, I meant that if you look at the end of that list of cases it says

UnListData -> 44 UnIData -> 45 UnBData -> 46 EqualsData -> 47 MkPairData -> 48 MkNilData -> 49 MkNilPairData -> 50

so it would be easy to think that the next free number is 51. Of course if we arrange them numerically then it moves VerifySECP256k1Signature away from the rest of the cryptographic builtins, so you get a different kind of confusion.

kwxm · 2022-02-07T12:49:51Z

plutus-core/untyped-plutus-core/test/Evaluation/Builtins/SECP256k1.hs

+          _         -> False)
+
+-- All data needed for an erroring case
+data SECP256k1ErrorCase =


I see that these are all in the order key/message/signature, which is different from the order of the input arguments. (Not a complaint, just a remark!)

kwxm · 2022-02-07T13:25:19Z

plutus-tx/src/PlutusTx/Builtins.hs

+-- appropriate form and length for SECP256k1. This function will error if any of
+-- these are not the case.
+verifySECP256k1Signature
+  :: BuiltinByteString -- ^ Public key


Could the comments here please say what lengths the input bytestrings should be, just so that it's documented here without having to consult the library? I was sure we had a comment about the valid inputs for verifySignature, but embarrassingly I can't find it; I'll fix that at the next opportunity.

kwxm · 2022-02-07T13:28:43Z

plutus-core/untyped-plutus-core/test/Evaluation/Builtins/SECP256k1.hs

+      SECP.Msg ->
+      Gen SECP256k1NoErrorCase
+    mkWrongKey sk pk msg = do
+      pkBad <- Gen.filter (/= pk) genPubKey


Very conscientious! Let's hope this filter isn't coming into play very often.

It's very unlikely. Assuming the generator is 'fair' (that is, any given key is equally likely to be generated), the probability that this filter would be tripped is 1 over (2^8)^32, due to pubkey lengths.

kwxm · 2022-02-07T13:34:35Z

plutus-tx/src/PlutusTx/Builtins.hs

+{-# INLINEABLE verifySECP256k1Signature #-}
+-- | Given a SECP256k1 public key, a SECP256k1 signature, and a SECP256k1
+-- message hash (all as 'BuiltinByteString's), verify the hash with that key and
+-- signature.


If I understand correctly, here the "message" is always a 32-byte hash of the real message (unlike verifySignature, which can take a message of any length). Does that hash have to be produced by any particular method, or will anything do? I'm wondering it we're ever going to have to produce the hashes on chain (which might require more new bultins), or if for real world applications it'll always be possible to generate the hashes off-chain and just perform the verification on the chain.

Basically, this is a concern outside of this builtin, cardano-base and even secp256k1-haskell! Specifically, secp256k1-haskell assumes you can somehow obtain this hash, and that's as far as its concerns go.

kwxm · 2022-02-07T13:35:45Z

plutus-tx/src/PlutusTx/Builtins.hs

+  -> Bool
+verifySECP256k1Signature pk sig msg =
+  fromBuiltin (BI.verifySECP256k1Signature pk sig msg)
+


I was going to suggest that this should take its arguments in the order key/message/signature for consistency with verifySignature, but I see that the argument order in both functions matches that of the underlying library function, and their arguments are in different orders. It looks as if we're doomed to inconsistency whatever we do.

Some digging through the repositories (with @michaelpj 's help) reveals that there is a DSIGN interface for Ed255911 as well. We should probably switch to using that for verifySignature instead, but unfortunately we won't be able to rearrange the arguments for reasons of backward compatibility. Anyway, the order above seems the right one for things using DSIGN and we should probably use the same order for any further signature checking functions we implement.

I agree that being consistent in some sense is better here, but this is a concern far outside this PR. I picked the argument order the way I did for precisely the reason you said: by matching the underlying library function, I minimize the amount of mistakes I would make by forgetting which argument goes where.

precisely the reason you said: by matching the underlying library function

I think I was wrong about that: see the comment in Crypto.hs. I'm thoroughly confused now though.

kwxm · 2022-02-07T14:05:34Z

plutus-core/plutus-core/src/Crypto.hs

+          emitM "SECP256k1: Given invalid message hash."
+          pure EvaluationFailure
+        Just msg' -> case DSIGN.verifyDSIGN () pk' msg' sig' of
+          Left _   -> pure . pure $ False


I don't understand all the stuff in DSIGN, but I see that the _ is a string. Is that something that would be worth logging in the Left case, or is it stuff that should be caught by the earlier checks anyway?

There's nothing to log; the implementation in secp256k1-haskell produces a Bool only.

kozross · 2022-02-07T18:27:31Z

@ysangkok Thank you for bringing this to our attention. We do indeed need Schnorr signature support; therefore, I'm marking this PR as WIP for now. I'll keep it current with plutus, but to add those will require me to do additional PRs to cardano-base at least, and possibly secp256k1-haskell as well.

@michaelpj and @kwxm: I have attempted, based on these instructions here and your feedback here, to generate a cost model for VerifySECP256k1Signature. However, after running cabal bench plutus-core:update-cost-model, the builtinCostModel.json doesn't seem to contain any reference to VerifySECP256k1Signature at all. I'm pretty sure I missed something, but I don't know what. The cost model in this case is fairly simple: the arguments are all fixed-width, so it should just be a constant function: I only don't know what said constant should be.

kwxm · 2022-02-07T23:07:56Z

I have attempted, based on these instructions here and #4375 (comment), to generate a cost model for VerifySECP256k1Signature.

@kozross Please undo this!!!! As mentioned in the second link above, these benchmarks MUST be run on a specific machine which at the moment only we have access to (unfortunately, but that's hard to change and there may even be legal difficulties because the machine is provided to us by an external party and we may be limited in who's allowed to access it). The changes to costModel.json involve drastic changes to the costing functions for all of the builtins and it would be disastrous to merge this because it would lead to significant changes in the costs of scripts. We need the costs to remain relatively consistent and to ensure this we have to use the same machine every time.

We can generate a suitable cost model once this PR is merged. In the meantime mempty will be OK, especially because the function should have constant cost.

I did send an email about this to the address on your GitHub account a few days ago, but I'm not sure if you got it.

kozross · 2022-02-07T23:17:36Z

@kwxm OK, I'll revert the change. I did receive your email, but the 'reference machine' part must have eluded me.

kwxm

(Sorry, I was trying to leave some comments and I seem to have started another review.)

kwxm · 2022-02-07T23:27:54Z

plutus-core/plutus-core/src/Crypto.hs

+        Nothing -> do
+          emitM "SECP256k1: Given invalid message hash."
+          pure EvaluationFailure
+        Just msg' -> case DSIGN.verifyDSIGN () pk' msg' sig' of


Oh wait! verifySECP256k1Signature takes its arguments in the order pk/sig/msg, but DSIGN.verifyDSIGN takes them in the order pk'/msg'/sig': see also the source of the instance here. Earlier I thought both of these took their arguments in the same order. Would it be reasonable to change the order of the arguments in the main function? That would make it consistent with the order expected by DSIGN (and also with the existing verifySignature function), which would be helpful if we ever implement other signature schemes covered by DSIGN.

kwxm · 2022-02-07T23:31:12Z

plutus-tx/src/PlutusTx/Builtins.hs

+  -> Bool
+verifySECP256k1Signature pk sig msg =
+  fromBuiltin (BI.verifySECP256k1Signature pk sig msg)
+


precisely the reason you said: by matching the underlying library function

I think I was wrong about that: see the comment in Crypto.hs. I'm thoroughly confused now though.

kwxm · 2022-02-07T23:34:34Z

@kwxm OK, I'll revert the change. I did receive your email, but the 'reference machine' part must have eluded me.

Thanks! I'm afraid that this situation's not very satisfactory, but it's not clear what else we can do at the moment. Eventually there'll have to be some community process for this kind of thing, but that's probably quite a long way off at the moment.

michaelpj · 2022-02-08T11:29:42Z

I'm glad we discovered the confusion about the signature algorithm before we merged this!

@kozross I'll let you work out what it is that you actually need, I guess the only thing to bear in mind for coming back to this PR is that we should indeed include the algorithm name as well as the curve in the name of the builtin, so we don't get confused in future.

michaelpj · 2022-04-19T12:38:21Z

Now the build issues are sorted out I think we can return to this. I'm not totally clear where we are on it: I think we're basically good to go? The failing builds are darwin (we have build machine issues, so it's disabled on master); merging master should fix that. And there are a few conflicts.

kozross · 2022-04-19T20:06:25Z

@michaelpj I've resolved the conflicts. Other than this, I believe the work is done: I have addressed reviewer concerns, I'm not aiming at any branches (such as for cardano-base), and the tests are present and passing.

Edit: Spoke too soon, it would seem. The parser error is really strange here, for two reasons:

The token it cannot parse is "verifyEcdsaSecp256k1Sign". This is wholly unsurprising, because that's not the name of any builtin.
The tokens it expected to see are not by any means the entire possible range of builtins.

Given that it first generates a TextualProgram, I suspect the issue is with the prettyprinter, but it could also be with the parser. I'm not familiar enough with the codebase to say for sure: how are these defined from the list of builtins? I assume the parser and prettyprinter are both derived somehow, but I don't know the logic that handles it.

michaelpj · 2022-04-20T09:13:54Z

plutus-tx-plugin/src/PlutusTx/Compiler/Builtins.hs

@@ -282,6 +284,8 @@ defineBuiltinTerms = do
    defineBuiltinTerm 'Builtins.lessThanEqualsByteString $ mkBuiltin PLC.LessThanEqualsByteString
    defineBuiltinTerm 'Builtins.emptyByteString $ PIR.mkConstant () BS.empty
    defineBuiltinTerm 'Builtins.decodeUtf8 $ mkBuiltin PLC.DecodeUtf8
+    defineBuiltinTerm 'Builtins.verifyEcdsaSecp256k1Signature $ mkBuiltin PLC.VerifyEcdsaSecp256k1Signature
+    defineBuiltinTerm 'Builtins.verifySchnorrSecp256k1Signature $ mkBuiltin PLC.VerifyEcdsaSecp256k1Signature


Suggested change

defineBuiltinTerm 'Builtins.verifySchnorrSecp256k1Signature $ mkBuiltin PLC.VerifyEcdsaSecp256k1Signature

defineBuiltinTerm 'Builtins.verifySchnorrSecp256k1Signature $ mkBuiltin PLC.VerifySchnorrSecp256k1Signature

I've fixed that (as well as the attendant golden test), but the issue with the parser roundtripping still happens.

michaelpj · 2022-04-21T09:14:58Z

The error message is hard to read because megaparsec errors don't Show well, but the issue is that you need to add cases for the new builtins to https://github.com/input-output-hk/plutus/blob/master/plutus-core/plutus-core/src/PlutusCore/Parser/Builtin.hs.

(@thealmarty can we make this list auto-generated so this doesn't happen in future? I think we should just be able to enumerate DefaultFun and populate the list with the value and its pretty-printed version.)

michaelpj · 2022-04-21T10:28:18Z

mlabs-haskell#5

effectfully · 2022-04-21T12:02:24Z

(@thealmarty can we make this list auto-generated so this doesn't happen in future? I think we should just be able to enumerate DefaultFun and populate the list with the value and its pretty-printed version.)

(It's how it used to be. Not only doing this automatically is way more convenient, but also allows us to handle sets of built-in functions other than DefaultFun)

thealmarty · 2022-04-21T15:16:27Z

(@thealmarty can we make this list auto-generated so this doesn't happen in future? I think we should just be able to enumerate DefaultFun and populate the list with the value and its pretty-printed version.)

(It's how it used to be. Not only doing this automatically is way more convenient, but also allows us to handle sets of built-in functions other than DefaultFun)

Ah yes, sorry about that. @effectfully mentioned that before the merge too. I will push a fix.

kozross · 2022-04-21T19:13:13Z

@michaelpj Yeah, I believe it used to work this way, and must have changed without my noticing.

kozross · 2022-04-21T20:01:03Z

I can't seem to reproduce this failure locally:

      deconstructorData2:             FAIL
        Test output was different from 'test/Plugin/Primitives/deconstructorData2.plc.golden'. Output of ["diff","-u","test/Plugin/Primitives/deconstructorData2.plc.golden","/build/deconstructorData2.plc13-54.actual"]:
        --- test/Plugin/Primitives/deconstructorData2.plc.golden        1970-01-01 00:00:01.000000000 +0000
        +++ /build/deconstructorData2.plc13-54.actual   2022-04-21 19:51:44.217039864 +0000
        @@ -239,6 +239,31 @@
                   (termbind
                     (strict)
                     (vardecl
        +              fst (all a (type) (all b (type) (fun [ [ (con pair) a ] b ] a)))
        +            )
        +            (builtin fstPair)
        +          )
        +          (termbind
        +            (strict)
        +            (vardecl
        +              snd (all a (type) (all b (type) (fun [ [ (con pair) a ] b ] b)))
        +            )
        +            (builtin sndPair)
        +          )
        +          (termbind
        +            (strict)
        +            (vardecl
        +              unsafeDataAsConstr
        +              (fun
        +                (con data)
        +                [ [ (con pair) (con integer) ] [ (con list) (con data) ] ]
        +              )
        +            )
        +            (builtin unConstrData)
        +          )
        +          (termbind
        +            (strict)
        +            (vardecl
                       chooseList
         <truncated>
        Use --accept or increase --size-cutoff to see full output.
        Use -p '/deconstructorData2/' to rerun this test only.

I had to repair a similar issue before, but on my local copy of my branch (which I just pushed), this test passes:

      deconstructData1:               OK
      deconstructorData2:             OK
      deconstructData2:               OK
      deconstructData3:               OK
    Data

michaelpj · 2022-04-22T08:57:42Z

I can't seem to reproduce this failure locally

I agree it's weird, but I suspect you can just revert the change contained in your PR, I suspect it will accept the old one.

thealmarty · 2022-04-22T14:48:09Z

That's a static test I don't see why it would do that either. Anyway lmk if you think the parser is suspicious. It seems my fix works.

kozross · 2022-04-22T18:53:25Z

@thealmarty - your fix looks like it worked. I also have no idea why this test fails.

michaelpj · 2022-04-25T09:29:32Z

What a saga. Thanks!

* Initial core support for SECP256k1 verification * Add SECP256k1 builtins for plutus-tx * Ensure tests for SECP256k1 pass * Use upstream cardano-base again * Fix a semantic conflict, fix 'stack' * Use EvaluationResult instead of Identity for Emit tracing * Attempt to bump haskell.nix * Try bumping nixpkgs * Ensure everything builds with newer cardano-base * Schnorr verification builtin and tests * Rename old SECP builtin for clarity, add Schnorr builtin * Add note about sequencing, Emitter and EvaluationFailure * Aim at cardano-base master for Schnorr support * Ensure Windows can find libsecp256k1 * Fix parser * Remove unused import * Fix plugin * Fix extra * Fix Windows build issues, update to use new Emitter * Renumber builtins to avoid clashes * Ensure the SECP builtins are shown as available * Ensure plutus-tx-plugin names SECP builtins properly * Roll back deconstructorData2 golden test Co-authored-by: effectfully <effectfully@gmail.com> Co-authored-by: Michael Peyton Jones <michael.peyton-jones@iohk.io>

kozross added 5 commits January 26, 2022 09:57

Initial core support for SECP256k1 verification

fe75d82

Add SECP256k1 builtins for plutus-tx

96f1a65

Merge branch 'master' into koz/secp256k1

8385d7e

Ensure tests for SECP256k1 pass

ddbadaa

Merge branch 'master' into koz/secp256k1

f318f1a

kozross changed the title ~~Koz/secp256k1~~ SECP256k1 support Feb 1, 2022

michaelpj requested a review from effectfully February 2, 2022 13:56

kozross added 2 commits February 4, 2022 07:37

Merge branch 'master' into koz/secp256k1

f404533

Use upstream cardano-base again

a7f3864

effectfully approved these changes Feb 5, 2022

View reviewed changes

effectfully added 2 commits February 5, 2022 09:49

Merge branch 'master' of https://github.com/input-output-hk/plutus in…

34917a5

…to mlabs-haskell-koz/secp256k1

Fix a semantic conflict, fix 'stack'

cee6a8a

kozross and others added 2 commits February 7, 2022 07:44

Merge pull request #2 from input-output-hk/mlabs-haskell-koz/secp256k1

4aad145

Merge `master` into `mlabs-haskell-koz/secp256k1` and fix what got broken

Use EvaluationResult instead of Identity for Emit tracing

4693f32

kwxm approved these changes Feb 7, 2022

View reviewed changes

kozross changed the title ~~SECP256k1 support~~ [WIP] SECP256k1 support Feb 7, 2022

kozross mentioned this pull request Feb 7, 2022

Automated costing #4384

Open

kozross force-pushed the koz/secp256k1 branch from baa97fb to 4693f32 Compare February 7, 2022 23:18

kwxm reviewed Feb 7, 2022

View reviewed changes

michaelpj marked this pull request as draft February 8, 2022 11:30

kozross added 2 commits March 18, 2022 08:05

Renumber builtins to avoid clashes

f825469

Merge branch 'master' into koz/secp256k1

ff89ede

kozross force-pushed the koz/secp256k1 branch from 0dbd531 to ff89ede Compare March 17, 2022 19:17

Ensure the SECP builtins are shown as available

bc61887

hamishmack mentioned this pull request Mar 18, 2022

Make DLLs in deps available to wine TH runner input-output-hk/haskell.nix#1405

Merged

Merge branch 'master' into koz/secp256k1

4931531

kozross force-pushed the koz/secp256k1 branch from a59b046 to 4931531 Compare April 19, 2022 19:59

michaelpj reviewed Apr 20, 2022

View reviewed changes

Ensure plutus-tx-plugin names SECP builtins properly

511e9d3

thealmarty mentioned this pull request Apr 21, 2022

Parse all DefaultFun builtin functions. #4546

Merged

9 tasks

Merge branch 'master' into koz/secp256k1

e39461b

kozross added 2 commits April 25, 2022 07:22

Merge branch 'master' into koz/secp256k1

fc7f918

Roll back deconstructorData2 golden test

6dadeaa

michaelpj merged commit 45cae06 into IntersectMBO:master Apr 25, 2022

kozross mentioned this pull request Apr 26, 2022

CIP-0049? | ECDSA and Schnorr signatures in Plutus Core cardano-foundation/CIPs#250

Merged

rmourey26 mentioned this pull request Feb 12, 2024

[Snyk] Security upgrade webpack-dev-server from 3.11.0 to 4.8.0 rmourey26/plutus#71

Open

	defineBuiltinTerm 'Builtins.verifySchnorrSecp256k1Signature $ mkBuiltin PLC.VerifyEcdsaSecp256k1Signature
	defineBuiltinTerm 'Builtins.verifySchnorrSecp256k1Signature $ mkBuiltin PLC.VerifySchnorrSecp256k1Signature

SECP256k1 support #4368

SECP256k1 support #4368

Conversation

kozross commented Feb 1, 2022 • edited Loading

ysangkok commented Feb 5, 2022

effectfully left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

effectfully commented Feb 5, 2022

effectfully commented Feb 5, 2022

michaelpj commented Feb 7, 2022

kwxm commented Feb 7, 2022

kwxm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kwxm Feb 7, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kozross commented Feb 7, 2022

kwxm commented Feb 7, 2022

kozross commented Feb 7, 2022

kwxm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kwxm commented Feb 7, 2022

michaelpj commented Feb 8, 2022

michaelpj commented Apr 19, 2022

kozross commented Apr 19, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michaelpj commented Apr 21, 2022

michaelpj commented Apr 21, 2022

effectfully commented Apr 21, 2022

thealmarty commented Apr 21, 2022

kozross commented Apr 21, 2022 • edited Loading

kozross commented Apr 21, 2022

michaelpj commented Apr 22, 2022

thealmarty commented Apr 22, 2022

kozross commented Apr 22, 2022

michaelpj commented Apr 25, 2022

kozross commented Feb 1, 2022 •

edited

Loading

kwxm Feb 7, 2022 •

edited

Loading

kozross commented Apr 19, 2022 •

edited

Loading

kozross commented Apr 21, 2022 •

edited

Loading