Trying to see, how this tx was successfully confirmed (in 2013) in the blockchain should reveal the secret of this script. The previous comments give already an idea, what the script is doing, but doesn't explain all. So I try to decompose further.
Assumption is, that sigscript of the spending tx goes to stack, then followed on top by the pubkey script. To verify the signature, the previous funding tx would need to be converted to an unsigned tx, so I remove the sig from orig tx, replace it with pubkey script, and change input script length:
01000000 01 A214A2DAF91691AFDD491FD00D894EB3301E35BC18B5554B14E12843037E954C (<-- reverse hex !)
00000000
23 (<-- length is decimal 35 Bytes, reversed, hex 0x23)
2102085C6600657566ACC2D6382A47BC3F324008D2AA10940DD7705A48AA2A5A5E33AC7C2103F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4AC7C5379A820D68DF9E32A147CFFA36193C6F7C43A1C8C69CDA530E1C6DB354BFABDCFEFAF3C875379A820F531F3041D3136701EA09067C53E7159C8F9B2746A56C3D82966C54BBC553226879A5479827701200122A59A5379827701200122A59A6353798277537982778779679A68 (<-- placed pkscript here into sigscript section)
00000000 (<-- interestingly, Sequence is not FFFFFFFF)
01 C06C3C0000000000 23 21039DC85F5FE062D4EEF0470FA96D4BBCFFF0096C62042333CD05AD491536560443AC DA538652
which is serialized and double sha256 hashed:
01000000014c957e034328e1144b55b518bc351e30b34e890dd01f49ddaf9116f9daa214a200000000B52102085C6600657566ACC2D6382A47BC3F324008D2AA10940DD7705A48AA2A5A5E33AC7C2103F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4AC7C5379A820D68DF9E32A147CFFA36193C6F7C43A1C8C69CDA530E1C6DB354BFABDCFEFAF3C875379A820F531F3041D3136701EA09067C53E7159C8F9B2746A56C3D82966C54BBC553226879A5479827701200122A59A5379827701200122A59A6353798277537982778779679A680000000001c06c3c00000000002321039dc85f5fe062d4eef0470fa96d4bbcfff0096c62042333cd05ad491536560443acda53865201000000
4eb4dccd727e81315a9ff801c205efc62635471cf8668e42c1c8aebfb51500a3
This double sha256 hash, pubkeys and sig (from the spending tx) matches with these pubkeys:
ssig1:
30450221009a29101094b283ae62a6fed68603c554ca3a624b9a78d83e8065edcf97ae231b02202cbed6e796ee6f4caf30edef8f5597a08a6be265d6601ad92283990b55c038fa
pubkey in HEX:
03F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4
pubkey in PEM:
MDYwEAYHKoZIzj0CAQYFK4EEAAoDIgAD9dD7lV+V3WvmEVzoVmHbQS7GoIq8v859oLqCl8bMDsQ=
double sha256:
4eb4dccd727e81315a9ff801c205efc62635471cf8668e42c1c8aebfb51500a3
ssig2:
3044022045d08719828fbd93e49c9223e63f4d2dab2de6c568e1faa2cccb33adf2575d2c02200c00126cb0105275040a963d91e45460147e40451b590485cf438606d3c784cf
pubkey in HEX:
02085C6600657566ACC2D6382A47BC3F324008D2AA10940DD7705A48AA2A5A5E33
pubkey in PEM:
MDYwEAYHKoZIzj0CAQYFK4EEAAoDIgACCFxmAGV1ZqzC1jgqR7w/MkAI0qoQlA3XcFpIqipaXjM=
double sha256:
4eb4dccd727e81315a9ff801c205efc62635471cf8668e42c1c8aebfb51500a3
Quick verification with openssl (hence the pubkey in PEM format):
sig=30450221009a29101094b283ae62a6fed68603c554ca3a624b9a78d83e8065edcf97ae231b02202cbed6e796ee6f4caf30edef8f5597a08a6be265d6601ad92283990b55c038fa
pk=03F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4
hash=4eb4dccd727e81315a9ff801c205efc62635471cf8668e42c1c8aebfb51500a3
printf $( echo $hash | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_utx_dsha256.hex
echo "MDYwEAYHKoZIzj0CAQYFK4EEAAoDIgAD9dD7lV+V3WvmEVzoVmHbQS7GoIq8v859oLqCl8bMDsQ=" > cat pubkey.pem
printf $( echo $sig | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_sig.hex
openssl pkeyutl <tmp_utx_dsha256.hex -verify -pubin -inkey pubkey.pem -sigfile tmp_sig.hex
OK, the part for the signature is clear. So looking further at the pkscript, I'll try to decode:
pubkey1 21 02085C6600657566ACC2D6382A47BC3F324008D2AA10940DD7705A48AA2A5A5E33 AC 7C
pubkey2 21 03F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4 AC 7C
53 79 A8
hash1 20 D68DF9E32A147CFFA36193C6F7C43A1C8C69CDA530E1C6DB354BFABDCFEFAF3C
87 53 79 A8
hash2 20 F531F3041D3136701EA09067C53E7159C8F9B2746A56C3D82966C54BBC553226
87 9A 54 79 82 77
01 20
01 22
A5 9A 53 79 82 77
01 20
01 22
A5 9A 63 53 79 82 77 53 79 82 77 87 79 67 9A 68
The problem I see is, that your statement somehow doesn't seem to match:
if (sha256(dat1) == hash1 &&
sha256(dat2) == hash2 &&
size(dat1) == 32 or 33 &&
size(dat2) == 32 or 33) {
if (size(dat1) == size(dat2)) {
return checksig(sig2, pk2);
} else {
return checksig(sig1, pk1);
}
The stack would look after sigscript:
[ssig2]
[ssig1]
[0x00]
[0x00]
And on top the pkscript would follow:
21: OP_DATA_0x21: length compressed Public Key (X9.63 form, 33 Bytes)
02085C6600657566:ACC2D6382A47BC3F:324008D2AA10940D:D7705A48AA2A5A5E:33
corresponding bitcoin address is: 152q849uVmoB5oRcZ4d4tJHyRuB6FPB9Hz
AC: OP_CHECKSIG: sig must be a valid sig for hash and pubkey
-- this would check the pubkey1 against ssig2, remove pubkey and [ssig2] from stack, and leave [TRUE] on stack
7C: OP_SWAP: top two items on stack are swapped
-- this would swap [ssig1][TRUE], so [ssig1] is on top of stack
21: OP_DATA_0x21: length compressed Public Key (X9.63 form, 33 Bytes)
03F5D0FB955F95DD:6BE6115CE85661DB:412EC6A08ABCBFCE:7DA0BA8297C6CC0E:C4
corresponding bitcoin address is: 1BaJ2fYiAVnZC73MtX1LsyJBtXNZWDSkt6
AC: OP_CHECKSIG: sig must be a valid sig for hash and pubkey
-- this would check the pubkey2 against ssig1, remove pubkey and [ssig1] from stack,
and leave [TRUE] on stack
[0x00][0x00][TRUE][TRUE]
7C: OP_SWAP: top two items on stack are swapped
-- this would swap [TRUE][TRUE], reason is unclear
53: OP_3: the number 3 is pushed onto stack
-- top stack element is "3"
[0x00][0x00][TRUE][TRUE][0x53]
79: OP_PICK: item n back in stack is copied to top
-- this would pop 1 element from stack, and bring [0x00] to the top of stack:
[0x00][0x00][TRUE][TRUE][0x00]
A8: OP_SHA256: input is hashed using SHA-256
20: OP_Data: next 32 bytes is data to be pushed on stack
D68DF9E32A147CFF:A36193C6F7C43A1C:8C69CDA530E1C6DB:354BFABDCFEFAF3C
87: OP_Equal: Returns 1 if inputs are equal, 0 otherwise
-- hashed the [0x00] value, put OP_DATA on top, and compare it. OP_EQUAL pops two
elements from stack. This would give [FALSE] on the stack. Stack status:
[0x00][0x00][TRUE][TRUE][FALSE]
53: OP_3: the number 3 is pushed onto stack
79: OP_PICK: item n back in stack is copied to top
-- this would pick the [TRUE] value ??
A8: OP_SHA256: input is hashed using SHA-256
20: OP_Data: next 32 bytes is data to be pushed on stack
F531F3041D313670:1EA09067C53E7159:C8F9B2746A56C3D8:2966C54BBC553226
87: OP_Equal: Returns 1 if inputs are equal, 0 otherwise
-- hashed the [0x00] value, put OP_DATA on top, and compare it. OP_EQUAL pops two elements from stack. This would give [FALSE] on the stack. Stack status: [0x00][0x00][TRUE][TRUE][FALSE][FALSE]
-- interestingly, this hash would match to sha256(hash) provided in the funding tx, as mentioned in the previous comment. I stop further evaluation of the script here. My understanding is, that we have seen the spending script with two hex 0x00 values, followed by sigs. This does not match the pseudo code? Maybe more like this:
if (sig1 == TRUE &&
sig2 == TRUE &&
sha256(dat1) == hash1 &&
sha256(dat2) == hash2 &&
size(dat1) == 32 or 33 &&
size(dat2) == 32 or 33)
...
However: I have somewhere an "off by one" at the second hash value (F531F3041D313670...). It should be OP_4 or OP_5 (instead of OP_3) to reach to one of the provided hash images. With the value 3 the OP_PICK would copy [TRUE] (from the sig verification) on top, instead the hash image at position 4 or 5...
I didn't follow the next opcodes, there are more conditions. Also sequence number is "00000000" (not "FFFFFFFF"), and LockTime is "DA538652" (decimal ), which is bigger than 500'000'000, meaning a unix timestamp. This translates to a date: Fr 15 Nov 2013 18:03:22 CET. The tx appeared in the blockchain on 2013-11-15 17:13:23.
So in summary I think, this tx was structured in a way, that someone gave out a keyword with the tx to a second party, and you needed to be able to sign and "know" the keyword. A type of multisig, yes. And, it could not be spent before a certain point in time (the tx would be kept in mempool, but we cannot see this anymore). Else only the owner would be able to spend the tx...
There is probably more to it, I leave it to the experts to decode the remaining part :-)
