From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RpkFa-0005Dd-Et for bitcoin-development@lists.sourceforge.net; Tue, 24 Jan 2012 17:33:42 +0000 X-ACL-Warn: Received: from netmind.hu ([85.17.45.8] helo=mail.netmind.hu) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1RpkFY-0004Um-7N for bitcoin-development@lists.sourceforge.net; Tue, 24 Jan 2012 17:33:42 +0000 Received: from [192.168.1.100] (188-195-182-160-dynip.superkabel.de [188.195.182.160]) by mail.netmind.hu (Postfix) with ESMTPSA id 4B4122E23E4 for ; Tue, 24 Jan 2012 18:31:09 +0100 (CET) Message-ID: <4F1EEB6D.8080004@netmind.hu> Date: Tue, 24 Jan 2012 18:33:33 +0100 From: =?UTF-8?B?QnJhdXRpZ2FtIFLDs2JlcnQ=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Bitcoin Development References: <4F1DBD07.3050904@netmind.hu> In-Reply-To: <4F1DBD07.3050904@netmind.hu> X-Forwarded-Message-Id: <4F1DBD07.3050904@netmind.hu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1RpkFY-0004Um-7N Subject: Re: [Bitcoin-development] ECC Signature Issue X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 17:33:42 -0000 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.