Document the non-DER-conformance of one test in tx_valid.json. #10679

It contains a non-DER-conformant ASN1 integer as a signature: 0xffda47bfc776bcd269da4832626ac332adfca6dd835e8ecd83cd1ebe7d709b0e

Please document how it's not DER conformant too.

Here is the code in BouncyCastle that checks ASN1 integers. How would you describe this code? Check if it's a "Two's complement"?

            if (bytes[0] == 0 && (bytes[1] & 0x80) == 0)
            {
                throw new IllegalArgumentException("malformed integer");
            }
            if (bytes[0] == (byte)0xff && (bytes[1] & 0x80) != 0)
            {
                throw new IllegalArgumentException("malformed integer");
            }

secp256k1 calls it "Excessive 0xFF padding" (and if it would pass that one, it's also negative) https://github.com/bitcoin-core/secp256k1/blob/master/src/ecdsa_impl.h#L120

So it's DER conformant just not strict DER conformant?

I think I would just call it negative. It's perfectly valid to encode negative numbers in DER but they don't make sense in signatures-- so for some inexplicable reason OpenSSL just ignored the sign.

Thanks, I changed the wording and added a reference to BIP66. What I don't understand is why this test is in tx_valid.json and not in tx_invalid.json. BIP66 declares such sigs as invalid. Or do the tests run pre-BIP66?

Each test specifies its own flags. If nothing is specified, the flags are 0, I believe. So no BIP66 rules in this test.

Merged via 31b2612bbf199fcbbb242fc1cfa2ad6221b0dcc7 (changed "excessive 0xff" in the description to "negative" per @gmaxwell)