Post by Gregory Maxwell
I think the latter is unlikely right now— but if the network doesn't
stop relaying these transactions it seems inevitable.
A patch was just merged in git head to enforce strict encodings for accepting
transactions into the memory pool. As miners and other nodes don't upgrade
immediately (and 0.8.2 isn't even released yet), this means such transactions
will likely still make it into blocks, but will have an increasingly harder
time doing so.
When the rate of non-standard encodings in the block chain has dropped far
enough, we can attempt scheduling a soft forking change to make it required.
At that point, the network rules will no longer depend on OpenSSL's parsers.
As a summary, here are the rules now enforced for acceptance into the memory
* 0. These rules are only applied for _evaluated_ scripts, as there is no
guaranteed way to know which data is supposed to be interpreted as a
public key or signature before actually evaluating the script. This
means that for example a 1-of-2 multisig can have an incorrectly-
encoded public key, but still be redeemed if a valid (and correctly
encoded) signature is given for the other key.
* 1. Public keys are either compressed (0x02 + 32 bytes, or 0x03 + 32 bytes)
or uncompressed (0x04 + 64 bytes). The non-standard "hybrid" encoding
supported by OpenSSL is not allowed.
* 2. Signatures are strictly DER-encoded (+ hashtype byte). The format is:
0x30 <lenT> 0x02 <lenR> <R> 0x02 <lenS> <S> <hashtype>
* R and S are signed integers, encoded as a big-endian byte sequence.
They are stored in as few bytes as possible (i.e., no 0x00 padding in
front), except that a single 0x00 byte is needed and even required
when the byte following it has its highest bit set, to prevent it
from being interpreted as a negative number.
* lenR and lenS are one byte, containing the length of the R and S
* lenT is one byte, containing the length of the complete structure
following it, starting from the 0x02, up to the S record. Thus, it
must be equal to lenR + lenS + 4.
* The hashtype is one byte, and is either 0x01, 0x02, 0x03, 0x81, 0x82
* No padding is allowed before or after the hashtype byte, thus lenT
is equal to the size of the whole signature minus 3.
* 3. These rules also apply to testnet.