why is this nonstandard

[grau]

Anybody could give me a hint why satoshi says the below transaction would be:

ERROR: CTxMemPool::accept() : nonstandard transaction input

As far as I see it only uses PUSH operators in scriptSig.

Code:

0100000002201ac3bea02ec2c3dcc86b123e5e0c53290e58ea5f7bf47154afbaec4f25c00700000000fdfe000000473044022022240b411509a86d9d092d0dfab636e981d36a19a5d3d20017f770173a3170ac02204fa7276400f3edea34b49edc9b0363e1be1ecdb017e8c74ba3ce56119715e2df0148304502205cd3a7972a7a4253b24b5607a18d60bdbc8d749de03ae1e68452ce5b0b559e75022100d929fb1cbf6191be76f379d4a24f6c5e89a58a4c45c437f3feaf27597688f33b014c695221031d11db38972b712a9fe1fc023577c7ae3ddb4a3004187d41c45121eecfdbb5b7210207ec36911b6ad2382860d32989c7b8728e9489d7bbc94a6b5509ef0029be128821024ea9fac06f666a4adc3fc1357b7bec1fd0bdece2b9d08579226a8ebde53058e453aeffffffff2312503f2491a2a97fcd775f11e108a540a5528b5d4dee7a3c68ae4add01dab300000000fd010100004930460221009f705343b234ce23814fb2487468bada931a87038194010dcb897e5fea48926e02210088e5fba6c25660fadc3f45f62590dbbf61eda188b42ecfcaa3f429405d31921e014930460221008ecf4cb533f31f160dcf1475fbfdb08768e8d89d058c61a3416ac69f7dda73e1022100829e47757b481413790846bb8c4f35ced12a52169eb53f3cecb39eaa618af095014c695221031d11db38972b712a9fe1fc023577c7ae3ddb4a3004187d41c45121eecfdbb5b7210207ec36911b6ad2382860d32989c7b8728e9489d7bbc94a6b5509ef0029be128821024ea9fac06f666a4adc3fc1357b7bec1fd0bdece2b9d08579226a8ebde53058e453aeffffffff02a0860100000000001976a914c9b99cddf847d10685a4fabaa0baf505f7c3dfab88ac701101000000000017a914b1ce99298d5f07364b57b1e5c9cc00be0b04a9548700000000

[1714119214]

1714119214

[1714119214]

1714119214

[1714119214]

1714119214

[1714119214]

1714119214

[1714119214]

1714119214

[piotr_n]

I think it's because the output script from the second output is kind of weird:

Code:

a914b1ce99298d5f07364b57b1e5c9cc00be0b04a95487

[piotr_n]

at the other hand, it seems that both the sigScript are inconsistent - so that is probably the reason.

Code:

01000000 - version
02 - two inputs

201ac3bea02ec2c3dcc86b123e5e0c53290e58ea5f7bf47154afbaec4f25c007-00000000 - 1st input txid-vout
fd:fe00 - length of sigScript 0xfe
00 - push null
00 - push null
47 - push 0x47 bytes:
 3044022022240b411509a86d9d092d0d
 fab636e981d36a19a5d3d20017f77017
 3a3170ac02204fa7276400f3edea34b4
 9edc9b0363e1be1ecdb017e8c74ba3ce
 56119715e2df01
48 - push 0x48 bytes:
 304502205cd3a7972a7a4253b24b5607
 a18d60bdbc8d749de03ae1e68452ce5b
 0b559e75022100d929fb1cbf6191be76
 f379d4a24f6c5e89a58a4c45c437f3fe
 af27597688f33b01
4c - push 0x4c bytes:
 695221031d11db38972b712a9fe1fc02
 3577c7ae3ddb4a3004187d41c45121ee
 cfdbb5b7210207ec36911b6ad2382860
 d32989c7b8728e9489d7bbc94a6b5509
 ef0029be128821024ea9fac0
6f - push 0x6f bytes:
 666a4adc3fc1357b7bec1fd0bdece2b9
 d08579226a8ebde53058e453ae
 [... where is the rest of the 0x6f bytes???]
ffffffff - sequence

2312503f2491a2a97fcd775f11e108a540a5528b5d4dee7a3c68ae4add01dab3-00000000 - 2nd input txid-vout
fd:0101 - length of sigScript 0x101
00 - push null
00 - push null
49 - push 0x49 bytes:
 30460221009f705343b234ce23814fb2
 487468bada931a87038194010dcb897e
 5fea48926e02210088e5fba6c25660fa
 dc3f45f62590dbbf61eda188b42ecfca
 a3f429405d31921e01
49 - push 0x49 bytes:
 30460221008ecf4cb533f31f160dcf14
 75fbfdb08768e8d89d058c61a3416ac6
 9f7dda73e1022100829e47757b481413
 790846bb8c4f35ced12a52169eb53f3c
 ecb39eaa618af09501
4c - push 0x4c bytes:
 695221031d11db38972b712a9fe1fc02
 3577c7ae3ddb4a3004187d41c45121ee
 cfdbb5b7210207ec36911b6ad2382860
 d32989c7b8728e9489d7bbc94a6b5509
 ef0029be128821024ea9fac06f666a4a
 dc3fc1357b7bec1fd0bdece2b9d08579
 226a8ebde53058e453ae
 [... seems 2 bytes are missing here as well]
ffffffff - sequence

02 - 2 outputs
a086010000000000 - value 1
19:76a914c9b99cddf847d10685a4fabaa0baf505f7c3dfab88ac - out script 1

7011010000000000 - value 2
17:a914b1ce99298d5f07364b57b1e5c9cc00be0b04a95487 - out script 1

00000000 - lock time

[grau]

Yes, the inputs are P2SH and one output is also P2SH.

The reason it was not considered standard as satoshi expects a 2 out of 3 signature to be exactly: (thanks to Gavin to point this out)
OP_0 <sig1> <sig2> OP_2  <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG

while I had
OP_0 OP_0 <sig1> <sig2> OP_2  <pubkey1> <pubkey2> <pubkey3> OP_3 OP_CHECKMULTISIG

the first OP_0 is to deal with a known satoshi bug, the second OP_0 being the placeholder for missing signature. This is valid in the script rules, but unfortunatelly not for the isStandard check.

So this is fixed now.

I am now fighting to figure what exactly needs to be hashed for the signature. BIP16 only says redemption script in place of the scriptPub,
but that does not yet cut it...

[grau]

Here is a more simple example, that is now considered standard, but invalid in signature

Code:

0100000001a5d11e3f73a7fd1072404333f9f45f37442066fd03a2fb212e0e1dbcb08c0bee00000000fdfe0000483045022100ff19f97eb58361365b8bd7ea4a14c7f07a8e4e63f09b464891dab97f04b44cd8022006b3c152bf25b2026072b7268feda8f45105209060064b72fc7972fbfa1b1f3f01483045022035eac71a8981e9119752199bb880f07321895fe441581da5e018d0afad694130022100e3670c62ca8fb2ff86aa5ac9818fb99615b42d0a74f1ce113b069521305f957e014c695221031d11db38972b712a9fe1fc023577c7ae3ddb4a3004187d41c45121eecfdbb5b7210207ec36911b6ad2382860d32989c7b8728e9489d7bbc94a6b5509ef0029be128821024ea9fac06f666a4adc3fc1357b7bec1fd0bdece2b9d08579226a8ebde53058e453aeffffffff0180380100000000001976a914c9b99cddf847d10685a4fabaa0baf505f7c3dfab88ac00000000

This is the parse from brainwallet.org:

Code:

{
    "hash": "9a9c346e13138b700f76f95168687dcbd59caae73c2bbd236c395af0ba12f4ed",
    "ver": 1,
    "vin_sz": 1,
    "vout_sz": 1,
    "lock_time": 0,
    "size": 341,
    "in": [
        {
            "prev_out": {
                "hash": "ee0b8cb0bc1d0e2e21fba203fd662044375ff4f93343407210fda7733f1ed1a5",
                "n": 0
            },
            "scriptSig": "OP_FALSE 3045022100ff19f97eb58361365b8bd7ea4a14c7f07a8e4e63f09b464891dab97f04b44cd8022006b3c152bf25b2026072b7268feda8f45105209060064b72fc7972fbfa1b1f3f01 3045022035eac71a8981e9119752199bb880f07321895fe441581da5e018d0afad694130022100e3670c62ca8fb2ff86aa5ac9818fb99615b42d0a74f1ce113b069521305f957e01 5221031d11db38972b712a9fe1fc023577c7ae3ddb4a3004187d41c45121eecfdbb5b7210207ec36911b6ad2382860d32989c7b8728e9489d7bbc94a6b5509ef0029be128821024ea9fac06f666a4adc3fc1357b7bec1fd0bdece2b9d08579226a8ebde53058e453ae",
            "sequence": 4294967295
        }
    ],
    "out": [
        {
            "value": "0.00080000",
            "scriptPubKey": "OP_DUP OP_HASH160 c9b99cddf847d10685a4fabaa0baf505f7c3dfab OP_EQUALVERIFY OP_CHECKSIG"
        }
    ]
}

The signature is invalid, but because I do not seem to compute the right hash to sign.

I use the redemption script in place of scriptPubScript but that is not yet sufficient...

[piotr_n]

I guess "what needs to be signed" is the ever lasting bitcoin question
I believe this took me the most effort to implement tx sign/verify in my client - there is no decent documentation on this.
The best you can do is to reverse engineer the satoshi's implementation.
Or or some other implementation that works... w.g. have a look at the function SignatureHash() here: (starts at line 102)
https://github.com/piotrnar/gocoin/blob/master/btc/tx.go

[grau]

The signature is invalid, but because I do not seem to compute the right hash to sign.

Everything was correct, only the order of signatures did not match the order of public keys