BIP-66 incompatible transactions?

[amaclin]

Are these txs BIP-66 compatible?
I think yes, but no one miner accepts them. Why?
https://blockchain.info/tx/81c2c3681cccd77dad4bcd41057381a5eaf1563fb9cc326269dd237573606703
inner p2sh script:
OP_1
0778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4 dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455 // invalid pubkey
0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 // chbs
OP_2
OP_CHECKMULTISIG
OP_NOT
https://blockchain.info/tx/04843f922a8a3eb5020cf7ea85f9ee9483faf8116665f8c18e1dcdcd40532756
inner p2sh script:
OP_1
0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 // chbs
0778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4 dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455 // invalid pubkey
OP_2
OP_CHECKMULTISIG
OP_NOT
https://blockchain.info/tx/8375bf35ee1a487f755637b283a2a28b947f61090ed3a41eba71e32934a9dbcc
inner p2sh script:
OP_1
0378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71 // chbs
0778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4 dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455 // invalid pubkey
OP_2
OP_CHECKMULTISIG

[fbueller]

Wiped out of the mempool perhaps, do you have the hexes?

[amaclin]

81c2c3681cccd77dad4bcd41057381a5eaf1563fb9cc326269dd237573606703

Code:

01000000017a5d7cd74adca569d9d37b5efb427e303e4b601a3ced35bab62a91095e84426b010000007500093006020101020101014c6851410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c7152ae91ffffffff01e875010000000000232103d68f90ba81455256cb7a0df14fb3930d6df61393207f2f3e71659414d296e0f0ac00000000

04843f922a8a3eb5020cf7ea85f9ee9483faf8116665f8c18e1dcdcd40532756

Code:

010000000114fc097241a58ebd2191d0c2a47603f8193536f2405b99b45d623598584dd390000000007500093006020101020101014c6851210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc345552ae91ffffffff01905f010000000000232103d68f90ba81455256cb7a0df14fb3930d6df61393207f2f3e71659414d296e0f0ac00000000

8375bf35ee1a487f755637b283a2a28b947f61090ed3a41eba71e32934a9dbcc

Code:

0100000001883e0501f87e9d3e10c02a721d4f5157319a725b5d5189bb5d9c1156ddbd832c00000000b2004730440220542bd08eb8bba6b539e9e25a8e444bca964b6528212405c294ef0cc9bb44205a022059e0c41b1a666182167be9f235d181736c6ff27ab0c0932ce0ad464cdafd3f15014c6751210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc345552aeffffffff01905f010000000000232103d68f90ba81455256cb7a0df14fb3930d6df61393207f2f3e71659414d296e0f0ac00000000

[arnuschky]

81c2c3681cccd77dad4bcd41057381a5eaf1563fb9cc326269dd237573606703

Code:

01000000017a5d7cd74adca569d9d37b5efb427e303e4b601a3ced35bab62a91095e84426b010000007500093006020101020101014c6851410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c7152ae91ffffffff01e875010000000000232103d68f90ba81455256cb7a0df14fb3930d6df61393207f2f3e71659414d296e0f0ac00000000

04843f922a8a3eb5020cf7ea85f9ee9483faf8116665f8c18e1dcdcd40532756

Code:

010000000114fc097241a58ebd2191d0c2a47603f8193536f2405b99b45d623598584dd390000000007500093006020101020101014c6851210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc345552ae91ffffffff01905f010000000000232103d68f90ba81455256cb7a0df14fb3930d6df61393207f2f3e71659414d296e0f0ac00000000

8375bf35ee1a487f755637b283a2a28b947f61090ed3a41eba71e32934a9dbcc

Code:

0100000001883e0501f87e9d3e10c02a721d4f5157319a725b5d5189bb5d9c1156ddbd832c00000000b2004730440220542bd08eb8bba6b539e9e25a8e444bca964b6528212405c294ef0cc9bb44205a022059e0c41b1a666182167be9f235d181736c6ff27ab0c0932ce0ad464cdafd3f15014c6751210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc345552aeffffffff01905f010000000000232103d68f90ba81455256cb7a0df14fb3930d6df61393207f2f3e71659414d296e0f0ac00000000

First two haven't been seen by my well-connected XT node. Third one has been seen but rejected:

Code:

2015-07-23 12:46:22 ERROR: CScriptCheck(): 8375bf35ee1a487f755637b283a2a28b947f61090ed3a41eba71e32934a9dbcc:0 VerifySignature failed: Public key is neither compressed or uncompressed
2015-07-23 12:46:22 ERROR: AcceptToMemoryPool: : ConnectInputs failed 8375bf35ee1a487f755637b283a2a28b947f61090ed3a41eba71e32934a9dbcc

[jl2012]

81c2c3681cccd77dad4bcd41057381a5eaf1563fb9cc326269dd237573606703

Code:

01000000017a5d7cd74adca569d9d37b5efb427e303e4b601a3ced35bab62a91095e84426b010000007500093006020101020101014c6851410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c7152ae91ffffffff01e875010000000000232103d68f90ba81455256cb7a0df14fb3930d6df61393207f2f3e71659414d296e0f0ac00000000

04843f922a8a3eb5020cf7ea85f9ee9483faf8116665f8c18e1dcdcd40532756

Code:

010000000114fc097241a58ebd2191d0c2a47603f8193536f2405b99b45d623598584dd390000000007500093006020101020101014c6851210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc345552ae91ffffffff01905f010000000000232103d68f90ba81455256cb7a0df14fb3930d6df61393207f2f3e71659414d296e0f0ac00000000

8375bf35ee1a487f755637b283a2a28b947f61090ed3a41eba71e32934a9dbcc

Code:

0100000001883e0501f87e9d3e10c02a721d4f5157319a725b5d5189bb5d9c1156ddbd832c00000000b2004730440220542bd08eb8bba6b539e9e25a8e444bca964b6528212405c294ef0cc9bb44205a022059e0c41b1a666182167be9f235d181736c6ff27ab0c0932ce0ad464cdafd3f15014c6751210378d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc345552aeffffffff01905f010000000000232103d68f90ba81455256cb7a0df14fb3930d6df61393207f2f3e71659414d296e0f0ac00000000

First two haven't been seen by my well-connected XT node. Third one has been seen but rejected:

Code:

2015-07-23 12:46:22 ERROR: CScriptCheck(): 8375bf35ee1a487f755637b283a2a28b947f61090ed3a41eba71e32934a9dbcc:0 VerifySignature failed: Public key is neither compressed or uncompressed
2015-07-23 12:46:22 ERROR: AcceptToMemoryPool: : ConnectInputs failed 8375bf35ee1a487f755637b283a2a28b947f61090ed3a41eba71e32934a9dbcc

is it rejected by consensus or just by standard-ness?

[arnuschky]

is it rejected by consensus or just by standard-ness?

It's rejected before being accepted into the Mempool, so it's standard-ness (Unless I misunderstood your question, there's no consensus rule that applies on mempool level, right?).

[HeadsOrTails]

It's rejected before being accepted into the Mempool, so it's standard-ness

Does this mean it fails the isStandard (ie it's a non-standard Tx)? (I'm learning  )

[amaclin]

Does this mean it fails the isStandard (ie it's a non-standard Tx)? (I'm learning  )

Yes. Today these transactions are non-standard.
I am wondering what BIP maked them non-standard and when?

[arnuschky]

Does this mean it fails the isStandard (ie it's a non-standard Tx)? (I'm learning  )

Yes. Today these transactions are non-standard.
I am wondering what BIP maked them non-standard and when?

BIP66 says:

The requirement to have signatures that comply strictly with DER has been enforced as a relay policy by the reference client since v0.8.0.

[jl2012]

Does this mean it fails the isStandard (ie it's a non-standard Tx)? (I'm learning  )

Yes. Today these transactions are non-standard.
I am wondering what BIP maked them non-standard and when?

I think standard-ness are just relay policy and not necessarily defined in BIP

There is no reason to allow invalid public key being recorded in the blockchain. It's an abuse of the system.

[amaclin]

I think standard-ness are just relay policy and not necessarily defined in BIP
There is no reason to allow invalid public key being recorded in the blockchain. It's an abuse of the system.

It was consensus code in past. Point.
I want to know who, when and why broke it

[arnuschky]

I think standard-ness are just relay policy and not necessarily defined in BIP
There is no reason to allow invalid public key being recorded in the blockchain. It's an abuse of the system.

It was consensus code in past. Point.
I want to know who, when and why broke it

If I understand things correctly, it wasn't consensus code in the past.
It was relay policy in bitcoin core from v0.8.0 onwards.
BIP66 proposed to make it a consensus rule, which was implemented in v0.10.0.

[amaclin]

If I understand things correctly, it wasn't consensus code in the past.
It was relay policy in bitcoin core from v0.8.0 onwards.
BIP66 proposed to make it a consensus rule, which was implemented in v0.10.0.

In fact these transactions are bip-66 compatible.
But there is a check now that all pubkeys for OP_CHECKMULTISIG must encoded right.
And the script verification fails with a message "Public key is neither compressed or uncompressed"
even the script contains correct signatures.