From: Chris Beams <chris@beams.io>
To: 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?
Date: Tue, 15 Apr 2014 18:39:35 +0200 [thread overview]
Message-ID: <981A0A04-EAE7-45BE-81FC-92A40A6B2DA4@beams.io> (raw)
In-Reply-To: <7270706.tTNIRFK64H@crushinator>
[-- Attachment #1: Type: text/plain, Size: 4654 bytes --]
Hi Matt,
Looks interesting. Is the source available?
On Apr 15, 2014, at 6:27 PM, Matt Whitlock <bip@mattwhitlock.name> wrote:
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 bothered this list. But since I did (and am now doing so again), I'll give a little more background on what we've been up to. It's not quite as simple as what I've shared thus far.
We have built a tool from scratch in C++ that is kind of a Swiss Army knife 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 this list before, and transaction building and signing. It has its own wallet 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 bitcoind's block data files. (It memory maps them and can do a full scan of the entire block chain in about a minute!) The wallet can contain keys, seeds, and multi-signature aggregates (which in turn can comprise keys and seeds). What we've been testing is deriving sequences of multi-sig P2SH addresses from a set of public seeds, sending bitcoins to those addresses, then using our tool to find those outputs in the block chain and to create transactions that redeem them, and then signing those trans
actions by supplying the private seeds to the tool.
Our tool is quite a bit easier to use than Bitcoind. (I was frankly appalled 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=$(./btctool pubkey < privseed1)
$ pubseed2=$(./btctool pubkey < privseed2)
$ pubseed3=$(./btctool pubkey < privseed3)
$ ./chaintool init
$ ./chaintool add demo 2 ":${pubseed1}" ":${pubseed2}" ":${pubseed3}"
$ ./chaintool ls
demo 2 :036447c7edc861b9f41fa0f611d81784f19ce692f37e8772b55c37c743cd526b49 :03c831711ea65decc06b0f3ccb4b9f1ba1a99a6933e520f6e7e4c3dbb4f015b701 :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": "6a9538f496f4c2d7f50c342fa6f6f76904a3b19f55f3a54a0003fc00b327d81b",
"vout": 1,
"address": "3GQd1tosFCE7Vo4TAiDHEKTaBgoyZTeL6R",
"scriptPubKey": "a914a1701be36532f05a74511fca89afce180c58189587",
"amount": 1000000,
"confirmations": 1
}
]
$ cat > outputs << EOF
13QAKNuh9uFcEiNAsct6LSF1qWQR6HLarT 50000
1FV4Fm3VCXfWy7BAXzT8t5qqTvEKZSad9v
EOF
$ tx=$(./chaintool createtx 10000 demo < outputs)
(I manually edited ${tx} at this point to add an OP_RETURN output. We're currently working toward using OP_RETURN in a provable solvency scheme.)
$ signedtx1=$(./chaintool signtx "${tx}" < privseed1)
input #0: need 1 of [:03c831711ea65decc06b0f3ccb4b9f1ba1a99a6933e520f6e7e4c3dbb4f015b701, :0347f2a0a346f21538fc451b95a600bc64ce5d2d28b89bf547697f3a77195d8dd1]
$ signedtx2=$(./chaintool signtx "${signedtx1}" < privseed2)
$ bitcoind sendrawtransaction "${signedtx2}"
b485b185c77d803f75e1ccfee1b5072846c9e0728f4c955ca40dce82263f8f16
$ exit
:-)
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]
next prev parent reply other threads:[~2014-04-15 16:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-15 15:00 [Bitcoin-development] Bug in 2-of-3 transaction signing in Bitcoind? Matt Whitlock
2014-04-15 15:05 ` Mike Hearn
2014-04-15 15:11 ` Pieter Wuille
2014-04-15 15:22 ` Matt Whitlock
2014-04-15 15:30 ` Mike Hearn
2014-04-15 15:42 ` Matt Whitlock
2014-04-15 15:47 ` Mike Belshe
2014-04-15 16:27 ` Matt Whitlock
2014-04-15 16:39 ` Chris Beams [this message]
2014-04-15 16:45 ` Matt Whitlock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=981A0A04-EAE7-45BE-81FC-92A40A6B2DA4@beams.io \
--to=chris@beams.io \
--cc=bip@mattwhitlock.name \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox