Does OP_CHECKSIG enforce the pubkey format?

[Bill White]

I have been looking at some unusual txouts in the block chain, e.g., the first 34 txouts of

237783998a6799264983150187a73ab6d116f2ba78d3e1f88529e95229f59d67

Bitcoin Core classifies them as "pubkey" type outputs. For example:

Code:

{
"value" : 0.00000001,
"n" : 0,
"scriptPubKey" : {
"asm" : "7d0800003b23280b343933313020383335393720303238353020313930303220373537373720363732333920303736343920353732383420393037373720323135 OP_CHECKSIG",
"hex" : "417d0800003b23280b343933313020383335393720303238353020313930303220373537373720363732333920303736343920353732383420393037373720323135ac",
"type" : "pubkey"
}

However, the (uncompressed) pubkey is usually 65 bytes of the form "04 x y". Here the leading byte is "7d".

To try to spend this txout, [a signature for*] this ill-formated "pubkey" would need to be given and I would expect the script to fail at OP_CHECKSIG. Is this correct? I can also imagine OP_CHECKSIG ignores the leading byte, but even in this case the (x,y) is not on the curve.

Does such a txout qualify as "provably unspendable"?

* Edit: added "a signature for"

[DannyHamilton]

- snip -
To try to spend this txout, this ill-formated "pubkey" would need to be given and I would expect the script to fail at OP_CHECKSIG. Is this correct? I can also imagine OP_CHECKSIG ignores the leading byte, but even in this case the (x,y) is not on the curve.
- snip -

Not only isn't it a valid pubkey, or on the curve...

But there appear to be an unusually large number of 0x3? and 0x20 bytes in there.  It really looks like someone was trying to code a set of 5 digit numbers in ascii and store the result in a bitcoin transaction output.  Perhaps they intended to use OP_RETURN and messed up?

 

[amaclin]

Does OP_CHECKSIG enforce the pubkey format?

No. And yes.
Consensus code does not require it.
Default node policy checks it for unconfirmed transactions.

I have been looking at some unusual txouts in the block chain, e.g., the first 34 txouts of

OP_CHECKSIG is not executing on output script of transactions

Does such a txout qualify as "provably unspendable"?

yes.

[Bill White]

Thank you for the replies.

Not only isn't it a valid pubkey, or on the curve...

But there appear to be an unusually large number of 0x3? and 0x20 bytes in there.  It really looks like someone was trying to code a set of 5 digit numbers in ascii and store the result in a bitcoin transaction output.  Perhaps they intended to use OP_RETURN and messed up?

I also suspect this was a way to embed some sort of data into the block chain. A similar, much larger transaction with over 300 ill-formed outputs is

657aecafe66d729d2e2f6f325fcc4acb8501d8f02512d1f5042a36dd1bbd21d1

Both of these txs are from April 2013.

[amaclin]

Perhaps they intended to use OP_RETURN and messed up?

OP_RETURN was non-standard in 2013

[DannyHamilton]

Perhaps they intended to use OP_RETURN and messed up?

OP_RETURN was non-standard in 2013

The OP didn't say anything about it being 2013.  I hadn't bothered checking the actual transaction, I just looked at the data that the OP posted.

[fbueller]

<unprintable characters>49310 83597 02850 19002 75777 67239 07649 57284 90777 215

With OP-RETURN being invalid, perhaps sending to a dud pay-to-pubkey allowed this to be achieved? It's beyond probability that this was a mistake as all of the hex characters map to valid integers between 0-9, and 0x20 (the space character) is used also.

There's something in there...

[amaclin]

With OP-RETURN being invalid, perhaps sending to a dud pay-to-pubkey allowed this to be achieved? It's beyond probability that this was a mistake as all of the hex characters map to valid integers between 0-9, and 0x20 (the space character) is used also.
There's something in there...

http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html

[fbueller]

I did some digging: the network does not enforce that public keys must be encoded correctly - this check is only active if the node's flags has the VERIFY_STRICTENC bit set.
This same bit controls some of the signature checks. If no other signature checks are set, the only part of the signature that's checked is the hashtype.

So, about VERIFY_STRICTENC. It's not a mandatory script-verification flag, however it's active by default in every nodes local policy. Nodes will not relay 0-conf transactions violating this rule, but if you COULD produce a redeeming transaction, you can send it directly to miners and make it into the blockchain.

Nice article amaclin - pity it doesn't explain this one!

[amaclin]

Nice article amaclin - pity it doesn't explain this one!

Let me do this homework for you.

1. Goto http://webbtc.com
2. Enter txid in the search field
3. Open transaction page http://webbtc.com/tx/237783998a6799264983150187a73ab6d116f2ba78d3e1f88529e95229f59d67
4. Click on [binary] link
5. Save tx as file
6. Open file in hex viewer

Code:

0000000000: 01 00 00 00 01 6C 17 EA │ CC BE B8 A7 CF 18 4F 9D  ☺   ☺l↨Ω╠╛╕º╧↑O¥
0000000010: C8 77 E4 C6 C1 47 4F 1A │ 8E 07 3D 7D 1C 83 27 28  ╚wΣ╞┴GO→Ä•=}∟â'(
0000000020: AB F0 17 C6 78 01 00 00 │ 00 6A 47 30 44 02 20 16  ½≡↨╞x☺   jG0D☻ ▬
0000000030: 37 44 F6 B7 B2 06 73 F2 │ 59 D4 C0 EC 4F 72 A4 4F  7D÷╖▓♠s≥Y╘└∞OrñO
0000000040: 53 AE 1D EC 2E AB C7 0F │ 6B 84 3C 00 D6 2F 56 02  S«↔∞.½╟☼kä< ╓/V☻
0000000050: 20 43 1F 47 55 24 C9 5E │ 8E CF 30 E1 E7 7B 3C C8   C▼GU$╔^Ä╧0ßτ{<╚
0000000060: BD A1 45 07 85 EE 5A 55 │ CD D4 BA A2 AF 8D 19 D1  ╜íE•àεZU═╘║ó»ì↓╤
0000000070: F8 01 21 03 C6 77 1A 35 │ A8 F3 EB 95 E7 DA DA 45  °☺!♥╞w→5¿≤δòτ┌┌E
0000000080: 32 26 4B 61 5C EF BB 09 │ 90 AB 89 77 92 99 03 65  2&Ka\∩╗○ɽëwÆÖ♥e
0000000090: 92 6F E4 2D FF FF FF FF │ 24 01 00 00 00 00 00 00  ÆoΣ-    $☺
00000000A0: 00 43 41 7D 08 00 00 3B │ 23 28 0B 34 39 33 31 30   CA}◘  ;#(♂49310
00000000B0: 20 38 33 35 39 37 20 30 │ 32 38 35 30 20 31 39 30   83597 02850 190
00000000C0: 30 32 20 37 35 37 37 37 │ 20 36 37 32 33 39 20 30  02 75777 67239 0
00000000D0: 37 36 34 39 20 35 37 32 │ 38 34 20 39 30 37 37 37  7649 57284 90777
00000000E0: 20 32 31 35 AC 01 00 00 │ 00 00 00 00 00 43 41 30   215¼☺       CA0
00000000F0: 32 20 30 38 36 33 32 20 │ 30 38 30 37 35 20 30 31  2 08632 08075 01
0000000100: 38 34 30 20 39 37 39 32 │ 36 20 32 37 38 38 35 20  840 97926 27885
0000000110: 30 39 37 36 35 20 38 38 │ 36 34 35 20 35 37 38 30  09765 88645 5780
0000000120: 32 20 30 31 33 36 36 20 │ 30 30 37 33 32 20 38 36  2 01366 00732 86
0000000130: AC 01 00 00 00 00 00 00 │ 00 43 41 37 39 35 20 34  ¼☺       CA795 4
0000000140: 34 37 33 34 20 31 31 32 │ 38 33 20 31 37 33 35 33  4734 11283 17353
0000000150: 20 36 37 38 33 31 20 32 │ 30 31 35 35 20 37 35 33   67831 20155 753
0000000160: 35 39 20 38 31 39 37 38 │ 20 35 34 35 30 35 20 34  59 81978 54505 4
0000000170: 38 31 31 35 20 37 31 39 │ 33 39 20 33 AC 01 00 00  8115 71939 3¼☺
0000000180: 00 00 00 00 00 43 41 34 │ 35 38 37 20 37 33 33 30       CA4587 7330
0000000190: 30 20 33 38 30 30 39 20 │ 39 33 32 36 31 20 39 35  0 38009 93261 95
00000001A0: 30 35 38 20 37 36 34 35 │ 32 20 35 30 32 33 38 20  058 76452 50238
00000001B0: 32 30 34 30 38 20 31 31 │ 30 31 38 20 39 38 38 35  20408 11018 9885
00000001C0: 30 20 34 32 36 31 35 20 │ AC 01 00 00 00 00 00 00  0 42615 ¼☺
00000001D0: 00 43 41 31 37 36 35 37 │ 20 39 39 34 31 37 20 30   CA17657 99417 0
00000001E0: 34 32 35 30 20 38 38 39 │ 30 33 20 37 30 32 39 31  4250 88903 70291
00000001F0: 20 31 39 30 31 35 20 38 │ 37 30 30 33 20 30 34 37   19015 87003 047
0000000200: 39 34 20 33 32 38 32 36 │ 20 30 37 33 38 32 20 31  94 32826 07382 1
0000000210: 34 36 39 35 AC 01 00 00 │ 00 00 00 00 00 43 41 20  4695¼☺       CA
0000000220: 34 31 35 37 30 20 33 33 │ 30 32 32 20 37 39 38 37  41570 33022 7987
0000000230: 35 20 35 37 36 38 31 20 │ 38 39 35 36 30 20 31 36  5 57681 89560 16
0000000240: 32 34 30 20 33 30 30 36 │ 34 20 31 31 31 35 31 20  240 30064 11151
0000000250: 36 39 30 30 38 20 37 32 │ 38 37 39 20 38 33 38 31  69008 72879 8381
0000000260: AC 01 00 00 00 00 00 00 │ 00 43 41 39 20 34 32 35  ¼☺       CA9 425
0000000270: 38 32 20 37 31 36 37 34 │ 20 35 36 34 37 37 20 34  82 71674 56477 4
0000000280: 38 31 36 36 20 38 34 33 │ 34 37 20 39 32 38 34 36  8166 84347 92846
0000000290: 20 34 35 38 30 39 20 32 │ 39 31 33 31 20 35 33 31   45809 29131 531
00000002A0: 38 36 20 30 30 37 30 30 │ 20 31 30 30 AC 01 00 00  86 00700 100¼☺
00000002B0: 00 00 00 00 00 43 41 34 │ 33 20 33 35 33 31 38 20       CA43 35318
00000002C0: 39 33 36 33 31 20 39 33 │ 34 33 39 20 31 32 39 34  93631 93439 1294
00000002D0: 38 20 36 30 34 34 35 20 │ 30 33 37 30 39 20 39 31  8 60445 03709 91
00000002E0: 39 38 30 20 30 34 37 37 │ 30 20 39 34 36 32 39 20  980 04770 94629
00000002F0: 32 31 35 35 38 20 31 38 │ AC 01 00 00 00 00 00 00  21558 18¼☺
0000000300: 00 43 41 30 37 31 20 31 │ 31 36 39 31 20 35 33 30   CA071 11691 530
0000000310: 33 31 20 38 37 36 32 38 │ 20 38 34 37 37 38 20 37  31 87628 84778 7
0000000320: 38 33 35 34 20 31 35 37 │ 35 39 20 33 32 38 39 31  8354 15759 32891
0000000330: 20 30 39 33 32 39 20 35 │ 34 34 37 33 20 35 30 38   09329 54473 508
0000000340: 38 31 20 38 AC 01 00 00 │ 00 00 00 00 00 43 41 38  81 8¼☺       CA8
0000000350: 32 34 36 20 35 34 39 35 │ 30 20 36 30 30 30 35 20  246 54950 60005
0000000360: 30 31 39 30 30 20 36 32 │ 37 34 37 20 30 35 33 30  01900 62747 0530
0000000370: 35 20 33 38 31 31 36 20 │ 34 32 37 38 32 20 39 34  5 38116 42782 94
0000000380: 32 36 37 20 34 37 34 38 │ 35 20 33 34 39 36 35 20  267 47485 34965
0000000390: AC 01 00 00 00 00 00 00 │ 00 43 41 32 35 37 34 35  ¼☺       CA25745

7. Note that transaction contains the numbers 49310 83597 02850 19002 etc
8. Google these numbers
9. Find this page: https://news.ycombinator.com/item?id=8055243

OK. I know nothing about "illegal primes" mentioned in the contents of this particular transaction.
Now it is your turn to continue the investigation  

[theymos]

why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?

That's already possible.  <pubkey> OP_CHECKSIG.  <pubkey> can be 33 to 120 bytes.

I also support a third transaction type for timestamp hash sized arbitrary data.  There's no point not having one since you can already do it anyway.  It would tell nodes they don't need to bother to index it.

[Bill White]

Thanks again everyone for the replies. My primary interest is not in the data apparently stored in the txouts, but whether or not they are provably unspendable.

Let me try to reformulate my question as a question about the scripting language:

If the "pubkey" on the stack is 65 bytes and the first byte is not 4, am I guaranteed that OP_CHECKSIG will result in 0?

[amaclin]

Let me try to reformulate my question as a question about the scripting language:
If the "pubkey" on the stack is 65 bytes and the first byte is not 4, am I guaranteed that OP_CHECKSIG will result in 0?

These outputs are provably unspendable. Under current consensus rules. Point.

(In fact I do not remember the result of OP_CHECKSIG in this case. Either 0 or 'script failed')