ECC Signature Issue

Hi all,

I'm working on a from scratch Java implementation. So far I got a modularized, unit tested implementation of the core modules (api, keys, blocks, chain, scripts, network protocol).

My dummy client however gets stuck on Block 140493, specifically at transaction hash: 70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d

It seems the (signature) verification fails for this specific transaction (for the 1 input in it), which is rather odd since verification was successful for all the preceding blocks and inputs.

I double checked that the official (C++) client is indeed successful here. Oddly enough the bitcoinj implementation also seems to fail to verify this transaction, which seems to point in the direction of BouncyCastle (which we both use).

My question is, did anybody hit this issue before? If not, can someone doublecheck maybe that I'm not missing something trivial?

The data that should be signed (the signature hash): b45c680f32f9364f5255cc15ef7cad879dbde9062d7fb8db0fe56e245823a78f

The signature (with '01' at the end for SIGHASH_ALL, remove this before you pass it to verification): 304402206b5c3b1c86748dcf328b9f3a65e10085afcf5d1af5b40970d8ce3a9355e06b5b0220cdbdc23e6d3618e47056fccc60c5f73d1a542186705197e5791e97f0e6582a3201

The public key: 04f25ec495fa21ad14d69f45bf277129488cfb1a339aba1fed3c5099bb6d8e9716491a14050fbc0b2fed2963dc1e56264b3adf52a81b953222a2180d48b54d1e18

As said, this seems to work with openssl, but seems to fail with bouncycastle for some reason (version 140).

Thanks, Robert.

> I double checked that the official (C++) client is indeed successful
> here. Oddly enough the bitcoinj implementation also seems to fail to
> verify this transaction, which seems to point in the direction of
> BouncyCastle (which we both use).

BitCoinJ does not verify signatures (it is an SPV implementation), so I'm not sure what you mean by this. Are you using old code? There used to be some stuff that checked signatures but it was removed some time ago.

On 01/23/2012 06:50 PM, Mike Hearn wrote:

>> I double checked that the official (C++) client is indeed successful
>> here. Oddly enough the bitcoinj implementation also seems to fail to
>> verify this transaction, which seems to point in the direction of
>> BouncyCastle (which we both use).
>
> BitCoinJ does not verify signatures (it is an SPV implementation), so
> I'm not sure what you mean by this. Are you using old code? There used
> to be some stuff that checked signatures but it was removed some time
> ago.

Hi Mike,

Bitcoinj has a class named ECKey. I just hardwired it with a main() to check the mentioned transaction's signature.

I debugged the official client to get the exact data (hash, signed data and public key). I checked signatures of transactions prior to the mentioned one, all work, so the test code and the data I got are very likely correct.

It might be that I'm using old bitcoinj code (I think it is 0.3, can't find a version string anywhere), but I doubt that has any impact on the ecc verification. Even if it did, I got my on code too, so what are the odds that two implementations fail at the same point?

Anyway it would be helpful if someone just tried to run a verification independently with the mentioned transaction (with BouncyCastle and with openssl) and see whether he/she gets the same result.

I tried with BouncyCastle 140 and the newest 1.46, both fail.

Robert.

Hi,

I'll reply to myself here, just to mention that the issue is solved.

Dave Hook from Bouncycastle replied that in the particular signature mentioned, one of the ASN1 encoded Integers is actually negative (which is not a valid coordinate for a point on a curve I assume). Since ASN1 integers are always signed, one has to pad "big" values with a zero byte to stay positive.

Workaround is easy for verification (convert to positive).

Robert.

On 01/24/2012 06:33 PM, Brautigam Róbert wrote:

> On 01/23/2012 06:50 PM, Mike Hearn wrote:
>>> I double checked that the official (C++) client is indeed successful
>>> here. Oddly enough the bitcoinj implementation also seems to fail to
>>> verify this transaction, which seems to point in the direction of
>>> BouncyCastle (which we both use).

...