Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X8OgJ-0000Lx-7X for bitcoin-development@lists.sourceforge.net; Sat, 19 Jul 2014 07:03:43 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.171 as permitted sender) client-ip=209.85.217.171; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f171.google.com; Received: from mail-lb0-f171.google.com ([209.85.217.171]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1X8OgI-0008Te-AR for bitcoin-development@lists.sourceforge.net; Sat, 19 Jul 2014 07:03:43 +0000 Received: by mail-lb0-f171.google.com with SMTP id l4so3519650lbv.30 for ; Sat, 19 Jul 2014 00:03:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.16.230 with SMTP id j6mr9867676lbd.90.1405753415609; Sat, 19 Jul 2014 00:03:35 -0700 (PDT) Received: by 10.112.35.138 with HTTP; Sat, 19 Jul 2014 00:03:35 -0700 (PDT) In-Reply-To: References: Date: Sat, 19 Jul 2014 00:03:35 -0700 Message-ID: From: Gregory Maxwell To: Richard Moore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1X8OgI-0008Te-AR Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Signature with negative integer? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 07:03:43 -0000 On Fri, Jul 18, 2014 at 9:33 PM, Richard Moore wrote: > Hey all, > I'm wondering if anyone can help explain to me tx 70f7c15c6f62139cc41afa8= 58894650344eda9975b46656d893ee59df8914a3d... 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=E2=80=94 of course).