1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
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 <pieter.wuille@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CAPg+sBhYuK79Gost2p1ksytNUTjAHz1REC1DRQaP2UD=cjRA0g@mail.gmail.com>
References: <CAPg+sBhYuK79Gost2p1ksytNUTjAHz1REC1DRQaP2UD=cjRA0g@mail.gmail.com>
Date: Sat, 13 Apr 2013 23:43:42 +0200
Message-ID: <CAPg+sBiPe25byk4UjMdUtBH-4wArgSVFGVnJgfyzMgjCn82Jxw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <pieter.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
> 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
<div dir=3D"ltr">On Sun, Apr 7, 2013 at 5:34 PM, Pieter Wuille <span dir=3D=
"ltr"><<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">piet=
er.wuille@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>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=A0<a href=3D"https://bitc=
ointalk.org/index.php?topic=3D169620.0" target=3D"_blank">https://bitcointa=
lk.org/index.php?topic=3D169620.0</a>=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.</div>
</div></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>--=A0</div><div style>Pieter</div><div styl=
e><br></div></div></div></div>
--047d7bdca2ecd7400a04da44e92a--
|
