summaryrefslogtreecommitdiff
path: root/b6/2683afcebed45bd5a6061d6e091942d6929525
blob: 23dabc6000fea224f79fd2eb3a72003dd37c80d0 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
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 <robert.brautigam@netmind.hu>) 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 <bitcoin-development@lists.sourceforge.net>;
	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?= <robert.brautigam@netmind.hu>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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.