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>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bug in 2-of-3 transaction signing in
	Bitcoind?
Precedence: list

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

:-)