Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Roxb7-0000jv-4N for bitcoin-development@lists.sourceforge.net; Sun, 22 Jan 2012 13:36:41 +0000 X-ACL-Warn: Received: from netmind.hu ([85.17.45.8] helo=mail.netmind.hu) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Roxb5-0002Zc-LO for bitcoin-development@lists.sourceforge.net; Sun, 22 Jan 2012 13:36:41 +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 07FE72E23E4 for ; Sun, 22 Jan 2012 14:16:06 +0100 (CET) Message-ID: <4F1C0CAB.4000905@netmind.hu> Date: Sun, 22 Jan 2012 14:18:35 +0100 From: =?ISO-8859-1?Q?Brautigam_R=F3bert?= 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 Content-Type: text/plain; charset=ISO-8859-1; 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: 1Roxb5-0002Zc-LO Subject: [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: Sun, 22 Jan 2012 13:36:41 -0000 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.