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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bip@mattwhitlock.name>) id 1Wa6D6-0002g7-DG
for bitcoin-development@lists.sourceforge.net;
Tue, 15 Apr 2014 16:27:48 +0000
X-ACL-Warn:
Received: from qmta05.westchester.pa.mail.comcast.net ([76.96.62.48])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Wa6D5-0005iK-BL for bitcoin-development@lists.sourceforge.net;
Tue, 15 Apr 2014 16:27:48 +0000
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59])
by qmta05.westchester.pa.mail.comcast.net with comcast
id qCkd1n0011GhbT855GTiY6; Tue, 15 Apr 2014 16:27:42 +0000
Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:219:d1ff:fe75:dc2f])
by omta07.westchester.pa.mail.comcast.net with comcast
id qGTh1n00j4VnV2P3TGThgV; Tue, 15 Apr 2014 16:27:42 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: Mike Belshe <mike@belshe.com>
Date: Tue, 15 Apr 2014 12:27:41 -0400
Message-ID: <7270706.tTNIRFK64H@crushinator>
User-Agent: KMail/4.12.4 (Linux/3.12.13-gentoo; KDE/4.12.4; x86_64; ; )
In-Reply-To: <CABaLYCu7by9AsurAcjzjo4QR_3Ln6DZrq7GPH_KxTokUbGTEeg@mail.gmail.com>
References: <1756895.gV83Q4MX2a@crushinator> <1832687.kEVurC5ttk@crushinator>
<CABaLYCu7by9AsurAcjzjo4QR_3Ln6DZrq7GPH_KxTokUbGTEeg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Sender: Matt Whitlock <bip@mattwhitlock.name>
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [76.96.62.48 listed in list.dnswl.org]
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Wa6D5-0005iK-BL
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bug in 2-of-3 transaction signing in
Bitcoind?
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: Tue, 15 Apr 2014 16:27:48 -0000
On Tuesday, 15 April 2014, at 8:47 am, Mike Belshe wrote:
> For what it is worth, I found btcd (the go implementation of bitcoind=
) has
> much better error/diagnostics messages. It would have given you more=
than
> "-22 TX Rejected". I used it to debug my own multi-sig transactions =
and it
> was very helpful.
I'll have to check that out.
A follow-up on my initial post... I did just successfully create, sign,=
and transmit another 2-of-3 transaction, so once again, I'm sorry I bo=
thered this list. But since I did (and am now doing so again), I'll giv=
e a little more background on what we've been up to. It's not quite as =
simple as what I've shared thus far.=20
We have built a tool from scratch in C++ that is kind of a Swiss Army k=
nife of Bitcoin. It does all sorts of key and address conversions, hash=
functions, encoding and decoding, script disassembly, BIP38 encryption=
/decrytion, the Shamir Secret Sharing that I've posted about here on th=
is list before, and transaction building and signing. It has its own wa=
llet and it's own UTXO cache that contains only TXOs that are relevant =
to the objects in its wallet. It synchronizes its cache by scanning bit=
coind's block data files. (It memory maps them and can do a full scan o=
f the entire block chain in about a minute!) The wallet can contain key=
s, seeds, and multi-signature aggregates (which in turn can comprise ke=
ys and seeds). What we've been testing is deriving sequences of multi-s=
ig P2SH addresses from a set of public seeds, sending bitcoins to those=
addresses, then using our tool to find those outputs in the block chai=
n and to create transactions that redeem them, and then signing those t=
ransactions by supplying the private seeds to the tool.
Our tool is quite a bit easier to use than Bitcoind. (I was frankly app=
alled at the command-line syntax that was necessary to get Bitcoind to =
sign a P2SH multi-sig transaction.)
$ ./btctool privkey < /dev/random > privseed1
$ ./btctool privkey < /dev/random > privseed2
$ ./btctool privkey < /dev/random > privseed3
$ pubseed1=3D$(./btctool pubkey < privseed1)
$ pubseed2=3D$(./btctool pubkey < privseed2)
$ pubseed3=3D$(./btctool pubkey < privseed3)
$ ./chaintool init
$ ./chaintool add demo 2 ":${pubseed1}" ":${pubseed2}" ":${pubseed3}"
$ ./chaintool ls
demo 2 :036447c7edc861b9f41fa0f611d81784f19ce692f37e8772b55c37c743cd=
526b49 :03c831711ea65decc06b0f3ccb4b9f1ba1a99a6933e520f6e7e4c3dbb4f015b=
701 :0347f2a0a346f21538fc451b95a600bc64ce5d2d28b89bf547697f3a77195d8dd1=
$ ./btctool addresses 1 2 "${pubseed1}" "${pubseed2}" "${pubseed3}"
3GQd1tosFCE7Vo4TAiDHEKTaBgoyZTeL6R
$ bitcoind sendtoaddress 3GQd1tosFCE7Vo4TAiDHEKTaBgoyZTeL6R 0.01
6a9538f496f4c2d7f50c342fa6f6f76904a3b19f55f3a54a0003fc00b327d81b
(I waited here for the tx to get into a block)
$ ./chaintool sync /var/lib/bitcoin/.bitcoin/blocks 2> /dev/null
$ ./chaintool listunspent
[
{
"txid": "6a9538f496f4c2d7f50c342fa6f6f76904a3b19f55f3a5=
4a0003fc00b327d81b",
"vout": 1,
"address": "3GQd1tosFCE7Vo4TAiDHEKTaBgoyZTeL6R",
"scriptPubKey": "a914a1701be36532f05a74511fca89afce180c=
58189587",
"amount": 1000000,
"confirmations": 1
}
]
$ cat > outputs << EOF
> 13QAKNuh9uFcEiNAsct6LSF1qWQR6HLarT 50000
> 1FV4Fm3VCXfWy7BAXzT8t5qqTvEKZSad9v
> EOF
$ tx=3D$(./chaintool createtx 10000 demo < outputs)
(I manually edited ${tx} at this point to add an OP_RETURN output. We'r=
e currently working toward using OP_RETURN in a provable solvency schem=
e.)
$ signedtx1=3D$(./chaintool signtx "${tx}" < privseed1)
input #0: need 1 of [:03c831711ea65decc06b0f3ccb4b9f1ba1a99a6933e520f6e=
7e4c3dbb4f015b701, :0347f2a0a346f21538fc451b95a600bc64ce5d2d28b89bf5476=
97f3a77195d8dd1]
$ signedtx2=3D$(./chaintool signtx "${signedtx1}" < privseed2)
$ bitcoind sendrawtransaction "${signedtx2}"
b485b185c77d803f75e1ccfee1b5072846c9e0728f4c955ca40dce82263f8f16
$ exit
:-)
|
