@jasonbcox it's still red, what am I supposed to do? If you want to refactor you can submit a revision and we can discuss that. The point of this Diff is only to clarify confusing code.

In D2373#53971, @deadalnix wrote:

Just add friend class CSignatureCacheTest and define CSignatureCacheTest in the test and access whatever you want through it.

Hmm IsSchnorrSignature is not done correctly here to be reused in CheckRawSignatureEncoding.

Out of curiosity I did some digging. The sigcache stuff dates back to 2012 and only came with a test of denial of service. Moved & renamed to CSignatureCache later that year.

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

In D2373#53777, @deadalnix wrote:

You'd expect there are some existing tests for the signature cache. but

$ grep -r ../src/test/ -e CachingTransactionSignatureChecker

returns nothing. This is rather concerning, but this absolutely require a test. The cache for script can be used as an example: https://reviews.bitcoinabc.org/source/bitcoin-abc/browse/master/src/test/txvalidationcache_tests.cpp

It's probably a good idea to write a test for it independent of this patch and then have the modified behavior only be added to the test in that patch.

In D2373#53753, @deadalnix wrote:

So the code looks good, but the new behavior is missing a test. You need to check that caching still works when flags like SCRIPT_VERIFY_MINIMALIF, but do hit a different key when SCRIPT_ENABLE_SCHNORR is passed.

replaced by D2377.

abandoning this in favour of an alternate approach: D2373 etc.

moved invariant flags to sigcache.cpp, some comment modifications.

abandoning this in favour of an alternate approach: D2373

@deadalnix still good?

oops, missed some .begin()s, now all changed to .data()

switched a few begin() to data(), strengthened internal sanity tests

Should I land this or wait for the diff testing system to be fixed?

In D2349#53148, @teamcity wrote:

Build Bitcoin-ABC / Diffs / Bitcoin-ABC Diff Testing failed.

oops, messed that up. trying again...

improve tests to check against ECDSA-Schnorr nonce reuse ; also fix braces

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

Added tests

Only one doubt: are there any external programs that call into this API?

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

What about this thing I had to run? update-alternatives --install /usr/bin/clang-format clang-format /usr/bin/clang-format-7 100 -- was that not needed when you grabbed it from apt.llvm.org?

In D2342#52945, @Mengerian wrote:

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.

linted

Looks good!

Note to observers: Much discussion about e selection was had in other avenues... interesting cryptography behind this.

In D2169#50483, @deadalnix wrote:

I'm not convinced that the mod approach is a good idea. In general this is known to be a problem. BIPSCHNORR argues that this is not a problem because the range of number that are twice as probable is small, but I'm not convinced this is desirable.

Seems good then. A couple more remarks added.

A few replies. I have to still review some other parts of code so some more comments may be coming.

A few comments. Most notably the computation of e should not be failing on overflow.

Added note that scriptPubKey / scriptCode committing obstructs Eltoo.

Just wondering, there are two implementations here, e.g., "secp256k1_schnorr_verify" and "secp256k1_schnorr_sig_verify". I understand one is from Amaury and one is from Pieter. What is the goal here, keep both or keep just one (and which?)?