From: Gregory Maxwell <gmaxwell@gmail•com>
To: Richard Moore <me@ricmoo•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Signature with negative integer?
Date: Sat, 19 Jul 2014 00:03:35 -0700 [thread overview]
Message-ID: <CAAS2fgT7Qk8nRZaKEMP7HzBXTVfzFmeBo3yFCHdwTTvMTrad5Q@mail.gmail.com> (raw)
In-Reply-To: <FD77BD8C-9772-41C4-B7B3-24F1E944B9E0@ricmoo.com>
On Fri, Jul 18, 2014 at 9:33 PM, Richard Moore <me@ricmoo•com> wrote:
> Hey all,
> I'm wondering if anyone can help explain to me tx 70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d...
A rather timely post. See the other thread on BIP0062. What you're
looking at is an example of a well-known-to-implementers-here where
invisible and undocumented "over permissiveness" in interpreting
invalid encoding in a cryptographic library (OpenSSL in our case)
which would have been probably-not-unwelcome in many other protocol
uses results in an unexpected consensus critical normative rule in
Bitcoin.
Modern releases of Bitcoin core will no longer relay or mine them but
they're still valid in blocks should they show up.
BIP62 proposes, among other things, soft-forking (backwards
compatible) changes that will strictly limit the DER encoding to avoid
ambiguity. If adopted by the network implementations would still need
to grandfather in existing weird transactions but could do so on a
txid by txid basis since there would be no more broken encoding
permitted in blocks, and use different DER decoding code without risk
of consensus inconsistency (so long as it uses der decoding which is
functionally identical to what BIP62 requires— of course).
prev parent reply other threads:[~2014-07-19 7:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-19 4:33 Richard Moore
2014-07-19 7:03 ` Gregory Maxwell [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=CAAS2fgT7Qk8nRZaKEMP7HzBXTVfzFmeBo3yFCHdwTTvMTrad5Q@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=me@ricmoo$(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