0

The scriptPubKey for cbebc4da731e8995fe97f6fadcd731b36ad40e5ecb31e38e904f6e5982fa09f7 is:

0x2102085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33ac7c2103f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4ac7c5379a820d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c875379a820f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226879a5479827701200122a59a5379827701200122a59a6353798277537982778779679a68

Whilst it's outpoint:

01000000023bec4b2a0193b3cb63cc3a263654f29606d032bf62dfd8f8579aca2f6a2b82a8000000004948304502210091abb9de9d785cc8b0129377d148d6458d283fb732785513f8217ae098f6a95702205de7fb76b028a3a2e6e8aea4b34a2309138013f696df1c26f3000df63ab0c72e01ffffffff2e0ac83f7b3674664811dbbb244ef05cf887049411f5c1dc6b4b53ea7dfec743000000006a483045022100fc458d74fd6c75e64a26d790f40135c2c28d0ad229c56c98891e94cdb1d5309902205d9d035f01d730b64ab3436319e7f1d989f52aa09295b32a650627e392819da001201b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227fffffffff01d09c790000000000b52102085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33ac7c2103f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4ac7c5379a820d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c875379a820f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226879a5479827701200122a59a5379827701200122a59a6353798277537982778779679a6800000000

The test vector spending it, cc60b1f899ec0a69b7c3f25ddf32c4524096a9c5b01cbd84c6d0312a0c478984, is:

0100000001f709fa82596e4f908ee331cb5e0ed46ab331d7dcfaf697fe95891e73dac4ebcb000000008c20ca42095840735e89283fec298e62ac2ddea9b5f34a8cbb7097ad965b87568100201b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227f483045022100a9df60536df5733dd0de6bc921fab0b3eee6426501b43a228afa2c90072eb5ca02201c78b74266fac7d1db5deff080d8a403743203f109fbcabf6d5a760bf87386d20100ffffffff01c075790000000000232103611f9a45c18f28f06f19076ad571c344c82ce8fcfe34464cf8085217a2d294a6ac00000000

The attached comments say cc60b1f8...d0312a0c478984, which is a fairly strange transaction which relies on OP_CHECKSIG returning 0 when checking a completely invalid sig of length 0

What on earth is going on here?

1 Answer 1

1

The scriptPubKey, decoded:

02085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33 OP_CHECKSIG OP_SWAP 03f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4 OP_CHECKSIG OP_SWAP OP_3 OP_PICK OP_SHA256 d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c OP_EQUAL OP_3 OP_PICK OP_SHA256 f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226 OP_EQUAL OP_BOOLAND OP_4 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_3 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_IF OP_3 OP_PICK OP_SIZE OP_NIP OP_3 OP_PICK OP_SIZE OP_NIP OP_EQUAL OP_PICK OP_ELSE OP_BOOLAND OP_ENDIF 

The scriptSig that spends the output, decoded:

ca42095840735e89283fec298e62ac2ddea9b5f34a8cbb7097ad965b87568100 1b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227f 3045022100a9df60536df5733dd0de6bc921fab0b3eee6426501b43a228afa2c90072eb5ca02201c78b74266fac7d1db5deff080d8a403743203f109fbcabf6d5a760bf87386d201 OP_FALSE

So they're combined, which results in:

ca42095840735e89283fec298e62ac2ddea9b5f34a8cbb7097ad965b87568100 1b1b01dc829177da4a14551d2fc96a9db00c6501edfa12f22cd9cefd335c227f 3045022100a9df60536df5733dd0de6bc921fab0b3eee6426501b43a228afa2c90072eb5ca02201c78b74266fac7d1db5deff080d8a403743203f109fbcabf6d5a760bf87386d201 OP_FALSE 02085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33 OP_CHECKSIG OP_SWAP 03f5d0fb955f95dd6be6115ce85661db412ec6a08abcbfce7da0ba8297c6cc0ec4 OP_CHECKSIG OP_SWAP OP_3 OP_PICK OP_SHA256 d68df9e32a147cffa36193c6f7c43a1c8c69cda530e1c6db354bfabdcfefaf3c OP_EQUAL OP_3 OP_PICK OP_SHA256 f531f3041d3136701ea09067c53e7159c8f9b2746a56c3d82966c54bbc553226 OP_EQUAL OP_BOOLAND OP_4 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_3 OP_PICK OP_SIZE OP_NIP 20 22 OP_WITHIN OP_BOOLAND OP_IF OP_3 OP_PICK OP_SIZE OP_NIP OP_3 OP_PICK OP_SIZE OP_NIP OP_EQUAL OP_PICK OP_ELSE OP_BOOLAND OP_ENDIF 

It checks a signature of zero-length OP_FALSE against the pubkey 02085c6600657566acc2d6382a47bc3f324008d2aa10940dd7705a48aa2a5a5e33 Obviously, that returns false. But it doesn't actually cause an error, because CHECKSIGVERIFY wasn't used. The rest of the script executes, and finally a non-zero value is left on the stack. Therefore, the transaction is valid.

Since the transaction is now in the blockchain, other clients must understand it too.

So what was this guy doing? Beats me.

3
  • It checks a signature of zero-length OP_FALSE against the pubkey: I'm confused on 2 things: 1) is a zero length sig just a single nullbyte? 2) but where does the 0b3eee... come from I'm the spending scriptSig? Aug 28, 2015 at 18:13
  • @WizardOfOzzie 1 No, it's a item of no bytes. See OP_FALSE on the wiki. 2 Not sure I understand. It comes from the third push in the scriptSig. (Although it doesn't start with that.)
    – Nick ODell
    Aug 28, 2015 at 18:21
  • Re 1) ahhhhhh, so None in Python. 2) don't mind me... Ipad was hiding the code in right margin Aug 28, 2015 at 18:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.