Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UR8Ee-0003yG-U6 for bitcoin-development@lists.sourceforge.net; Sat, 13 Apr 2013 21:43:48 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.210.172 as permitted sender) client-ip=209.85.210.172; envelope-from=pieter.wuille@gmail.com; helo=mail-ia0-f172.google.com; Received: from mail-ia0-f172.google.com ([209.85.210.172]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UR8Ee-00059v-0l for bitcoin-development@lists.sourceforge.net; Sat, 13 Apr 2013 21:43:48 +0000 Received: by mail-ia0-f172.google.com with SMTP id k38so3389182iah.3 for ; Sat, 13 Apr 2013 14:43:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.30.104 with SMTP id r8mr2310257igh.9.1365889422561; Sat, 13 Apr 2013 14:43:42 -0700 (PDT) Received: by 10.50.92.4 with HTTP; Sat, 13 Apr 2013 14:43:42 -0700 (PDT) In-Reply-To: References: Date: Sat, 13 Apr 2013 23:43:42 +0200 Message-ID: From: Pieter Wuille To: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7bdca2ecd7400a04da44e92a X-Spam-Score: -0.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 (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1UR8Ee-00059v-0l Subject: Re: [Bitcoin-development] Who is creating non-DER signatures? 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, 13 Apr 2013 21:43:49 -0000 --047d7bdca2ecd7400a04da44e92a Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 7, 2013 at 5:34 PM, Pieter Wuille wrote: > I've monitored all transactions the past weeks (1.4M transactions), and it > seems 9641 of them contain at least one non-standard signature. See > https://bitcointalk.org/index.php?topic=169620.0 for a list of the top > addresses that had coins used as inputs in such transactions. If you > recognize any of these addresses, or have an idea of who owns them or what > software they are using, please let me know. > Without significant effort, I don't think we're going to be able to get that number down. I'd like to stress that without making these non-standard encodings effectively invalid on the network, pretty much every full node implementation needs to depend on OpenSSL to guarantee compatibility (and that is hoping OpenSSL doesn't change its supported encodings), or make assumptions about which deviations are allowed. The next question, I guess, is at which transaction frequency it's acceptable to move forward with this? The first step is definitely just not accepting them into memory pools, but leaving them valid inside blocks. Actual network rules will need to come later. However, even just not accepting them into memory pools will it make very hard (if not impossible) for the buggy clients that create transactions to get any confirmations. I'm not sure... 0.6% isn't much, but 9600 transactions is. -- Pieter --047d7bdca2ecd7400a04da44e92a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 7, 2013 at 5:34 PM, Pieter Wuille <piet= er.wuille@gmail.com> wrote:
I've monitored all= transactions the past weeks (1.4M transactions), and it seems 9641 of them= contain at least one non-standard signature. See=A0https://bitcointa= lk.org/index.php?topic=3D169620.0=A0for a list of the top addresses tha= t had coins used as inputs in such transactions. If you recognize any of th= ese addresses, or have an idea of who owns them or what software they are u= sing, please let me know.

Without significant effort, I = don't think we're going to be able to get that number down. I'd= like to stress that without making these non-standard encodings effectivel= y invalid on the network, pretty much every full node implementation needs = to depend on OpenSSL to guarantee compatibility (and that is hoping OpenSSL= doesn't change its supported encodings), or make assumptions about whi= ch deviations are allowed.

The next question, I guess, is at which tra= nsaction frequency it's acceptable to move forward with this? The first= step is definitely just not accepting them into memory pools, but leaving = them valid inside blocks. Actual network rules will need to come later. How= ever, even just not accepting them into memory pools will it make very hard= (if not impossible) for the buggy clients that create transactions to get = any confirmations. I'm not sure... 0.6% isn't much, but 9600 transa= ctions is.

--=A0
Pieter

--047d7bdca2ecd7400a04da44e92a--