📅 Original date posted:2012-01-24
📝 Original message: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.
Brautigam Róbert [ARCHIVE] /
npub17v…4nw5q
2023-06-07 02:57:26
in reply to nevent1q…3e45
Author Public Key
npub17vt9s8f4fwjvrzscfqmdgdaq0zn2ephnqs53jynr8x6hu6vsd7wqm4nw5qPublished at
2023-06-07 02:57:26Event JSON
{
"id": "0bf420666b51c8ad695df0b007780166fe22c30a90a2464a6c5c0b1c6080b549",
"pubkey": "f316581d354ba4c18a184836d437a078a6ac86f3042919126339b57e69906f9c",
"created_at": 1686106646,
"kind": 1,
"tags": [
[
"e",
"b38bb34b55a69853b6ddad60097eabdc2fab3de87b544bb01dc0808cb0ea1c97",
"",
"root"
],
[
"e",
"5e528b5e6d670b48eaaa0703f4f78dc66117db94134081b0be91d160b6f74b0f",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2012-01-24\n📝 Original message:On 01/23/2012 06:50 PM, Mike Hearn wrote:\n\u003e\u003e I double checked that the official (C++) client is indeed successful\n\u003e\u003e here. Oddly enough the bitcoinj implementation also seems to fail to\n\u003e\u003e verify this transaction, which seems to point in the direction of\n\u003e\u003e BouncyCastle (which we both use).\n\u003e\n\u003e BitCoinJ does not verify signatures (it is an SPV implementation), so\n\u003e I'm not sure what you mean by this. Are you using old code? There used\n\u003e to be some stuff that checked signatures but it was removed some time\n\u003e ago.\n\nHi Mike,\n\nBitcoinj has a class named ECKey. I just hardwired it with a main() to\ncheck the mentioned transaction's signature.\n\nI debugged the official client to get the exact data (hash, signed data\nand public key). I checked signatures of transactions prior to the\nmentioned one, all work, so the test code and the data I got are very\nlikely correct.\n\nIt might be that I'm using old bitcoinj code (I think it is 0.3, can't\nfind a version string anywhere), but I doubt that has any impact on the\necc verification. Even if it did, I got my on code too, so what are the\nodds that two implementations fail at the same point?\n\nAnyway it would be helpful if someone just tried to run a verification\nindependently with the mentioned transaction (with BouncyCastle and with\nopenssl) and see whether he/she gets the same result.\n\nI tried with BouncyCastle 140 and the newest 1.46, both fail.\n\nRobert.",
"sig": "5504f10689be98ebfc5a169502dbd4762af8421358ab070c357d9339dac516d723557a6316b9cef0e673d2dc4500364d626dff96a623b1254383701b00583af7"
}