Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago My mistake - actually in block 168868 (next block)
Transaction hash:
9ec12d075981d5cc53dd500b712e02cb6c52144d5b9a7b631d72eec532624d58
Here it is on blockexplorer:
http://blockexplorer.com/testnet/tx/9ec12d075981d5cc53dd500b712e02cb6c52144d5b9a
7b631d72eec532624d58Original comment by alex@bitpos.me on 30 Jan 2014 at 4:00
GoogleCodeExporter
commented
9 years ago OK, I've done some analysis here.
The stack that is failing in executeMultiSig looks like the following:
byte[0]
byte[73] (Sig 1)
byte[72] (Sig 2)
byte[1] (Sig count == 2)
byte[0] ? not expected to be here by the function
byte[33] (Pub key 1)
byte[33] (Pub key 2)
byte[1] (Key count == 3!)
The first thing you'll notice is the key count is 3, not 2 (as there are 2 keys)
So the function bombs out when it goes to read the (non-existant) third key.
Additionally, there is the phantom byte[0] between the pubkeys and the
sig-count.
Interestingly, if I massage the data using the debugger - I.e. i manually set
the keyCount to be 2, and do a pollLast on the stack to 'remove' the phantom
byte, then the script executes correctly. Thoughts?
Original comment by alex@bitpos.me on 30 Jan 2014 at 4:47
GoogleCodeExporter
commented
9 years ago I think the second byte[0] (aka OP_0) is a valid pubkey for bitcoind, as long
as there's no signature attempted for that key. So this is a bug in bitcoinj.
The throw statement should be removed from bitcoinj.Original comment by c1.devra...@niftybox.net on 30 Jan 2014 at 4:53
GoogleCodeExporter
commented
9 years ago Ahh, of course! I must be blind - I didn't think that could be a public key.
I'll prepare a patch.Original comment by alex@bitpos.me on 30 Jan 2014 at 4:55
GoogleCodeExporter
commented
9 years ago It looks like the fault is in:
LinkedList<byte[]> pubkeys = new LinkedList<byte[]>();
for (int i = 0; i < pubKeyCount; i++) {
byte[] pubKey = stack.pollLast();
if (pubKey.length == 0)
throw new ScriptException("Attempted OP_CHECKMULTISIG(VERIFY) with a pubkey of length 0");
pubkeys.add(pubKey);
}
That pubKey.length check should be at most a warning. If the sig fails for
that key, then it will be caught lower down anyway...Original comment by alex@bitpos.me on 30 Jan 2014 at 5:00
GoogleCodeExporter
commented
9 years ago Agreed.Original comment by c1.devra...@niftybox.net on 30 Jan 2014 at 6:13
GoogleCodeExporter
commented
9 years ago This can be pulled from my fork here:
https://code.google.com/r/alex-postgres/source/browse/core/src/main/java/com/goo
gle/bitcoin/script/Script.java?spec=svna458bc1a2ccb35756827c939aaf082f114a6241d&
r=a458bc1a2ccb35756827c939aaf082f114a6241dOriginal comment by alex@bitpos.me on 30 Jan 2014 at 7:51
GoogleCodeExporter
commented
9 years ago I dont see a fix there?Original comment by BlueMatt...@gmail.com on 30 Jan 2014 at 7:54
GoogleCodeExporter
commented
9 years ago Line 1162. Unfortunately it got rolled into the same commit as my postgres
work (oops)
The actual change is a 'throw new Exception' -> log.warnOriginal comment by alex@bitpos.me on 30 Jan 2014 at 7:57
GoogleCodeExporter
commented
9 years ago Oh, I was looking at the next commit (your commits are titled strangely...)
In any case, I'm gonna just remove that whole if in both places and remove the
whole section in OP_CHECKSIG in a minute when I finish writing test cases for
all this crap.Original comment by BlueMatt...@gmail.com on 30 Jan 2014 at 7:59
GoogleCodeExporter
commented
9 years ago Yep, that works for me :)Original comment by alex@bitpos.me on 30 Jan 2014 at 8:01
GoogleCodeExporter
commented
9 years ago Resolved by
https://code.google.com/p/bitcoinj/source/detail?r=28b24d0eaa8c75df7afdc43f5d78b
5ffd85003e9Original comment by BlueMatt...@gmail.com on 30 Jan 2014 at 8:52
Original issue reported on code.google.com by
alex@bitpos.meon 30 Jan 2014 at 3:57