Page MenuHomePhabricator

WIP: add Schnorr opcode support

Authored by markblundeberg on Jan 19 2019, 03:30.


Group Reviewers
Restricted Project
Maniphest Tasks
T527: Add Schnorr support to OP_CHECKSIG and OP_CHECKDATASIG

This implements
Actually, this codes a variant where the flag byte is removed and instead
Schnorr are identified by size. It is however easy to convert to flag byte.

Depends on D2169 (secp256k1 schnorr upgrade)

Test Plan

need to add tests, among them:

  • - script with tests of flag activation
  • - test op_checkmultisig still accepts 64 byte ECDSA
  • - many more...

Diff Detail

rABC Bitcoin ABC
Lint SkippedExcuse: lint is throwing exception, will config later
No Unit Test Coverage
Build Status
Buildable 4576
Build 7215: Bitcoin ABC Buildbot (legacy)
Build 7214: arc lint + arc unit

Event Timeline

markblundeberg created this revision.Jan 19 2019, 03:30
Herald added a reviewer: Restricted Project. · View Herald TranscriptJan 19 2019, 03:30
Herald added a subscriber: schancel. · View Herald Transcript

Question, regarding this To Do item: "test op_checkmultisig still accepts 64 byte ECDSA"

Would it make sense to restrict MultiSig to non-64-byte ECDSA? If the plan is to eventually implement Schnorr on MultiSig also, I just wonder if avoiding 64-byte ECDSA would be better.

markblundeberg added a comment.EditedJan 19 2019, 05:49

Question, regarding this To Do item: "test op_checkmultisig still accepts 64 byte ECDSA"

Would it make sense to restrict MultiSig to non-64-byte ECDSA? If the plan is to eventually implement Schnorr on MultiSig also, I just wonder if avoiding 64-byte ECDSA would be better.

Good question, I've been thinking about it a lot.

Here are some thoughts on the possible mechanics, put elsewhere as they are beyond the scope of this Diff:
As you can see, I don't think it's possible to make a new OP_CHECKMULTISIG mechanism that triggers based on discriminating among Schnorr/ECDSA signatures themselves, without having ambiguity issues. This is because of the problem of OP_0 being a legal "signature" in some cases. Because of that, I don't think it will help us at all to forbid 64-byte ECDSA within the multisigs at this time.

deadalnix requested changes to this revision.Jan 19 2019, 13:30

This is going to get big real quick and I suggest you start splitting this up in logicial chunks. There is one immediate item that appear to distinguish itself, it is the renaming of various function that assume simply "signing" to make it explicit they are using ECDSA. Theses are simple change that do not affect how the codebase function in any way and could be merged quickly. It would also ensure the rest of the change stands out and are easier to review as a result.

For isntance:

  • CheckTransactionSignatureEncoding => CheckTransactionECDSASignatureEncoding
  • CKey::Sign => CKey::SignECDSA
  • CPubKey::Verify => CPubKey::VerifyECDSA
898 ↗(On Diff #6741)

CheckTransactionSignatureEncoding is passed the flags, so it knows if it is admissible that this is a shnorr signature. This whole thing should be internal mechanic of checking the signature encoding, IMO.

32 ↗(On Diff #6741)

D not add bool parameters to functions if it can be avoided. It makes for terrible API. See for instance.

105 ↗(On Diff #6741)

Simply adding this flag + tests checking that it does nothing should be a diff on its own.

43 ↗(On Diff #6741)

What is the goal of this ?

229 ↗(On Diff #6741)

It's required we accept this for NULLFAILto work properly anyways.

35 ↗(On Diff #6741)

You are passed the flags down, so it is probably the respectability of that function to check if the encoding correspond to schnorr and is enabled or not rather than the caller.

This revision now requires changes to proceed.Jan 19 2019, 13:30
markblundeberg planned changes to this revision.Jan 19 2019, 15:41

OK, thanks for the quick feedback! I will fix the booling API. I can split this diff up like so for starters:

  • "trivial" Diff that merely alters the names/APIs of existing functions in obvious ways.
  • Diff that adds new Schnorr accessory functions but they are unused. Relevant tests of these functions such as possible interaction with ECDSA (like via sigcache).
  • Diff that adds the new flag and modifies evalscript mechanics; heavy testing.
898 ↗(On Diff #6741)

CheckTransactionSignatureEncoding gets used in CHECKMULTISIG too, where schnorrs are inadmissible regardless of flags. It's a bit awkward, but the whole logic of this diff is built around the fact that it is the responsibility of opcodes in EvalScript to already decide whether a signature ought to be put into the ECDSA or Schnorr pipelines. (the specification will have to be clarified on this front, it's an important conceptual point)

32 ↗(On Diff #6741)

Yes, it's possible to do it with duplicated API instead.

105 ↗(On Diff #6741)

OK. Makes sense.

43 ↗(On Diff #6741)

If we do the unflagged 64-byte signature approach, I think this explicit distinguishing is important for consensus security.

Consider the case where a valid 64-byte ECDSA signature is put into the cache somehow: either during pre-upgrade or from checkmultisig. It then gets maliciously reused post-upgrade as a "Schnorr" signature. This is supposed to fail since it is an incorrect schnorr signature, but it would instead pass due to cache lookup.

I think I know how to turn this into an attack where an attacker could cause a mining node to mine only invalid blocks, but it's too elaborate to get into here...

229 ↗(On Diff #6741)


Actually right now only length=65 sigs get passed to CheckTransactionSchnorrSignatureEncoding. However in future when we add the new Schnorr CHECKMULTISIG mechanics, this function will be getting inputs of all lengths. I am going to rewrite the logic here.

35 ↗(On Diff #6741)

ditto to previous comment

Currently this diff being split into D2345 D2347 D2348 ... more to come.

deadalnix added inline comments.Jan 20 2019, 00:50
43 ↗(On Diff #6741)

I see.

markblundeberg abandoned this revision.Jan 22 2019, 01:58

Obsolete. This is being replaced by other Diffs that can be seen in T527