Clarifying BIP62 Zero-padded number pushes

[jl2012]

In BIP62, it says

Zero-padded number pushes Any time a script opcode consumes a stack value that is interpreted as a number, it must be encoded in its shortest possible form. 'Negative zero' is not allowed. See reference: Numbers.

The native data type of stack elements is byte arrays, but some operations interpret arguments as integers. The used encoding is little endian with an explicit sign bit (the highest bit of the last byte). The shortest encodings for numbers are (with the range boundaries encodings given in hex between ()).

0: OP_0; (00)
1..16: OP_1..OP_16; (51)..(60)
-1: OP_1NEGATE; (79)
-127..-2 and 17..127: normal 1-byte data push; (01 FF)..(01 82) and (01 11)..(01 7F)
-32767..-128 and 128..32767: normal 2-byte data push; (02 FF FF)..(02 80 80) and (02 80 00)..(02 FF 7F)
-8388607..-32768 and 32768..8388607: normal 3-byte data push; (03 FF FF FF)..(03 00 80 80) and (03 00 80 00)..(03 FF FF 7F)
-2147483647..-8388608 and 8388608..2147483647: normal 4-byte data push; (04 FF FF FF FF)..(04 00 00 80 80) and (04 00 00 80 00)..(04 FF FF FF 7F)
Any other numbers cannot be encoded.
In particular, note that zero could be encoded as (01 80) (negative zero) if using the non-shortest form is allowed.

If I try to use non-standard push in the scriptPubKey, without zero-padding, would that be allowed? For example, is the scriptPubKey "5101019C" spendable under BIP62?

Code:

OP_1 OP_PUSHDATA(01) OP_NUMEQUAL

Currently, I think this is spendable with an empty scriptSig.

[jl2012]

There are few more edge cases I would like to clarify:

1. The use of non-standard push in scriptPubKey (Based on the BIP62 description I think this is allowed)

2. The use of non-standard push in P2SH serialized script

3. The use of zero-padded number in scriptPubKey or P2SH serialized script (I think this is not allowed)

4. The use of non-standard push but not zero-padded number in scriptPubKey (the original question)

5. The use of non-standard push but not zero-padded number in P2SH serialized script

6. The use of zero-padded number in scriptPubKey or P2SH serialized script (I think this is not allowed)

7. The use of non-DER or high-S signatures in scriptPubKey or P2SH serialized script (I think this is not allowed)

8. The use of something not an empty byte as the extra stake element for CHECKMULTISIG in scriptPubKey or P2SH serialized script (I think this is not allowed)

9. The use of empty byte, but not a direct result of OP_0 (e.g. "OP_0 OP_ABS" or "0100"), as the extra stake element for CHECKMULTISIG in scriptPubKey or P2SH serialized script .

10. Having more than one item left in the stake due to the design of scriptPubKey (e.g. scriptSig = empty; scriptPubKey = OP_1 OP_1) (I think this is not allowed)

I think all these cases are currently allowed and would not cause any malleability.

[johoe]

BIP 62 only protects scriptSig.  The other parts are not malleable by third party.

• scriptPubKey in outputs are (usually) signed
• P2SH script has to match its hash in the input transaction's scriptPubKey

update:  Okay I posted to fast.  There are some more checks that also apply for other script types.  I leave it to others to clarify this.

[gmaxwell]

No restrictions can be placed on scriptPubKeys or redeemscript-content without potentially confiscating people's Bitcoins.