From: Pieter Wuille <pieter.wuille@gmail•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Who is creating non-DER signatures?
Date: Mon, 15 Apr 2013 13:51:02 +0200 [thread overview]
Message-ID: <20130415115100.GA31477@vps7135.xlshosting.net> (raw)
In-Reply-To: <CAAS2fgS-zaX+imRccY2TtjDxgR+4kgNkmYy0EAN4FJgect2+rA@mail.gmail.com>
On Sat, Apr 13, 2013 at 02:58:21PM -0700, Gregory Maxwell wrote:
> 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
pool:
* 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
records, respectively.
* 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
or 0x83.
* 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.
Cheers,
--
Pieter
prev parent reply other threads:[~2013-04-15 11:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-07 15:34 Pieter Wuille
2013-04-07 16:01 ` Mike Hearn
2013-04-07 16:21 ` Pieter Wuille
2013-04-13 21:43 ` Pieter Wuille
2013-04-13 21:58 ` Gregory Maxwell
2013-04-15 11:51 ` Pieter Wuille [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130415115100.GA31477@vps7135.xlshosting.net \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox