hhanh00 (OP)
|
|
October 21, 2014, 10:14:57 AM |
|
There are a few Pay2SH transactions that I can't validate. For example, https://blockchain.info/tx/567a53d1ce19ce3d07711885168484439965501536d0d0294c5d46d46c10e53bThe script hash matches but the script uses OP_RIGHT. OP_1 OP_RIGHT 6e879169907c9087 OP_RIGHT s a disabled op code. Shouldn't the script fail? It's not the only example. We have 6 other scripts that use disabled opcodes and yet are part of the blockchain. Another one, harder for me to understand https://blockchain.info/tx/5df1375ffe61ac35ca178ebb0cab9ea26dedbd0e96005dfcee7e379fa513232fOf all the P2SH cases in the blockchain, my tool only rejects this one. It looks like a standard 2 of 3 multisig. The 2nd signature is a SIGHASH_SINGLE but the first one is a regular SIGHASH_ALL. Yet, none of the provided public keys seems to match the first one either. There must be something wrong with my tool but I don't see where. I could run another client but it will take hours before it catches up to this point. A standalone verifier would be great. Because usually, the issue is in the way I built the transaction to sign. Is there such a tool available? I tried decoderawtransaction - it doesn't give much information. { "txid" : "5df1375ffe61ac35ca178ebb0cab9ea26dedbd0e96005dfcee7e379fa513232f", "version" : 1, "locktime" : 0, "vin" : [ { "txid" : "b5b598de91787439afd5938116654e0b16b7a0d0f82742ba37564219c5afcbf9", "vout" : 0, "scriptSig" : { "asm" : "30450221008dd619c563e527c47d9bd53534a770b102e40faa87f61433580e04e271ef2f960220029886434e18122b53d5decd25f1f4acb2480659fea20aabd856987ba3c3907e01 022b78b756e2258af13779c1a1f37ea6800259716ca4b7f0b87610e0bf3ab52a01", "hex" : "4830450221008dd619c563e527c47d9bd53534a770b102e40faa87f61433580e04e271ef2f960220029886434e18122b53d5decd25f1f4acb2480659fea20aabd856987ba3c3907e0121022b78b756e2258af13779c1a1f37ea6800259716ca4b7f0b87610e0bf3ab52a01" }, "sequence" : 4294967295 }, { "txid" : "ab9805c6d57d7070d9a42c5176e47bb705023e6b67249fb6760880548298e742", "vout" : 0, "scriptSig" : { "asm" : "0 3045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303 30460221008431bdfa72bc67f9d41fe72e94c88fb8f359ffa30b33c72c121c5a877d922e1002210089ef5fc22dd8bfc6bf9ffdb01a9862d27687d424d1fefbab9e9c7176844a187a01 52483045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c7153ae", "hex" : "00483045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a53034930460221008431bdfa72bc67f9d41fe72e94c88fb8f359ffa30b33c72c121c5a877d922e1002210089ef5fc22dd8bfc6bf9ffdb01a9862d27687d424d1fefbab9e9c7176844a187a014c9052483045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c7153ae" }, "sequence" : 4294967295 } ], "vout" : [ { "value" : 0.00100000, "n" : 0, "scriptPubKey" : { "asm" : "OP_HASH160 d8dacdadb7462ae15cd906f1878706d0da8660e6 OP_EQUAL", "hex" : "a914d8dacdadb7462ae15cd906f1878706d0da8660e687", "reqSigs" : 1, "type" : "scripthash", "addresses" : [ "3MTdzi2J1qqge4MsGykL7K461JuSwNqwko" ] } } ] }
Thanks for your help
|
|
|
|
|
|
|
|
|
"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
trattrat
|
|
October 21, 2014, 01:27:57 PM |
|
Some miners will include strange transactions.
|
|
|
|
hhanh00 (OP)
|
|
October 21, 2014, 01:48:54 PM |
|
Are they allowed to include invalid transactions?
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1075
Ian Knowles - CIYAM Lead Developer
|
|
October 21, 2014, 01:49:49 PM |
|
Are they allowed to include invalid transactions?
If they are invalid then other nodes would reject them - so I don't think that they could be *invalid*.
|
|
|
|
hhanh00 (OP)
|
|
October 21, 2014, 01:51:47 PM |
|
Cool but how can they be valid? They have disabled op codes.
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
October 21, 2014, 02:03:40 PM |
|
OP_RIGHT s a disabled op code. Shouldn't the script fail?
Definitely must fail. This is a bug on blockchain.info site In fact the script is 51 // PUSH 1 0181 // PUSH -1 08 6e879169907c9087 // PUSH p2sh inner script There are no disabled opcodes in this script
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
October 21, 2014, 02:15:13 PM |
|
Another one, harder for me to understand https://blockchain.info/tx/5df1375ffe61ac35ca178ebb0cab9ea26dedbd0e96005dfcee7e379fa513232fOf all the P2SH cases in the blockchain, my tool only rejects this one. It looks like a standard 2 of 3 multisig. The 2nd signature is a SIGHASH_SINGLE but the first one is a regular SIGHASH_ALL. Yet, none of the provided public keys seems to match the first one either. There must be something wrong with my tool but I don't see where. My advise: take bitcoin-qt sources (local copy just for test this tx) and pass this transaction to the validation method under debugging.
|
|
|
|
Buffer Overflow
Legendary
Offline
Activity: 1652
Merit: 1015
|
|
October 21, 2014, 02:18:39 PM |
|
I guess the miner had isStandard() flag disabled in their config for these transactions to be in the blockchain if they are nonstandard.
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
October 21, 2014, 02:20:47 PM |
|
I guess the miner had isStandard() flag disabled in their config for these transactions to be in the blockchain if they are nonstandard.
First transaction mined by Eligius. This pool has its own IsStandard ( )
|
|
|
|
luv2drnkbr
|
|
October 21, 2014, 02:20:49 PM |
|
Can somebody explain how 0x81 translates to -1? I get the 0x01 code to push the 0x81 byte, but I don't understand why it's a -1.
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
October 21, 2014, 02:24:48 PM |
|
Can somebody explain how 0x81 translates to -1? I get the 0x01 code to push the 0x81 byte, but I don't understand why it's a -1.
The highest bit is sign. 0x81 = 0x80 + 0x01 BTW: 0x80 itself is "negative zero"
|
|
|
|
luv2drnkbr
|
|
October 21, 2014, 02:29:20 PM |
|
How is that determined? Is there a data format not listed on the wiki about scripts?
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
October 21, 2014, 02:33:49 PM |
|
How is that determined? Is there a data format not listed on the wiki about scripts?
Everything in wiki. Have you read it? https://en.bitcoin.it/wiki/ScriptThe stacks hold byte vectors. When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). Positive 0 is represented by a null-length vector. Byte vectors are interpreted as Booleans where False is represented by any representation of zero, and True is represented by any representation of non-zero.
|
|
|
|
luv2drnkbr
|
|
October 21, 2014, 02:36:50 PM |
|
Whoops. I scrolled past that, looking at op codes. Thanks for the explanation!
|
|
|
|
hhanh00 (OP)
|
|
October 21, 2014, 04:00:27 PM |
|
Thanks, turned out my mistake was somewhere else. Regarding the last script, OP_FALSE 3045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303 30460221008431bdfa72bc67f9d41fe72e94c88fb8f359ffa30b33c72c121c5a877d922e1002210089ef5fc22dd8bfc6bf9ffdb01a9862d27687d424d1fefbab9e9c7176844a187a01 52483045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c7153ae
The first signature is in the redeem script and has to be removed before it is inserted into the transaction to sign. I was missing this part since for a standard tx, the signature is in the input script.
|
|
|
|
Nicolas Dorier
|
|
October 24, 2014, 05:28:35 PM Last edit: October 24, 2014, 05:42:50 PM by Nicolas Dorier |
|
The 2nd input of https://blockchain.info/tx/5df1375ffe61ac35ca178ebb0cab9ea26dedbd0e96005dfcee7e379fa513232f is 0 3045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009 f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303 30460221008431bdfa72bc67f9d41fe72e94c88fb8f359ffa30b33c72c121c5a877d922e1002210 089ef5fc22dd8bfc6bf9ffdb01a9862d2
With redeem script being 2 3045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009 f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303 0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 3 OP_CHECKMULTISIG} NBitcoin.Script
In other words, a p2sh multi sig. Blockchain is bugged. C# code with NBitcoin : var tx = new BlockrTransactionRepository().Get(new uint256("5df1375ffe61ac35ca178ebb0cab9ea26dedbd0e96005dfcee7e379fa513232f"));
Console.WriteLine(tx.Inputs[1].ScriptSig); var redeemScript = new PayToScriptHashTemplate() { VerifyRedeemScript = false }.ExtractScriptSigParameters(tx.Inputs[1].ScriptSig).RedeemScript; Console.WriteLine(redeemScript);
The funny thing is that the redeemScript is not correct. It is a 2 - 3 except that there is only one correctly formed public key. This make it non redeemable. UPDATE : It was indeed spent. Investigating this miracle. UPDATE 2 : My fault, there is 2 valid public key but one invalid one. Which means the spender stuffed data in the redeem.
|
Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
October 24, 2014, 06:29:16 PM |
|
UPDATE 2 : My fault, there is 2 valid public key but one invalid one. Which means the spender stuffed data in the redeem. Update 3: there is one public key used twice 2 3045022015bd0139bcccf990a6af6ec5c1c52ed8222e03a0d51c334df139968525d2fcd20221009 f9efe325476eb64c3958e4713e9eefe49bf1d820ed58d2112721b134e2a1a5303 0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 3 OP_CHECKMULTISIG
|
|
|
|
hhanh00 (OP)
|
|
October 25, 2014, 06:40:46 AM |
|
Someone should do a best of the blockchain. Some whacked scripts are in there.
|
|
|
|
|
Nicolas Dorier
|
|
October 25, 2014, 10:50:53 AM |
|
Maybe this one might is an old attempt at DDOS when the number of sig operation were not limited ? (OP_CHECKSIG do not return from the script, so every op is evaluated) ... maybe most likely a bug, I think OP_CHECKSIG consume the stack so the other one should not be able to execute.
|
Bitcoin address 15sYbVpRh6dyWycZMwPdxJWD4xbfxReeHe
|
|
|
bernard75
Legendary
Offline
Activity: 1316
Merit: 1003
|
|
October 25, 2014, 09:58:10 PM |
|
Still going strong.
|
|
|
|
hhanh00 (OP)
|
|
October 26, 2014, 01:55:03 AM |
|
Maybe this one might is an old attempt at DDOS when the number of sig operation were not limited ? (OP_CHECKSIG do not return from the script, so every op is evaluated) ... maybe most likely a bug, I think OP_CHECKSIG consume the stack so the other one should not be able to execute. Yes, and it leaves a boolean on the stack which will be used as an arg to the next CHECKSIG. It's not a good DDOS because the script isn't redeemable and doesn't have to be checked at all.
|
|
|
|
|