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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1X8Vtu-0005YX-AR
for bitcoin-development@lists.sourceforge.net;
Sat, 19 Jul 2014 14:46:14 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.169 as permitted sender)
client-ip=209.85.213.169; envelope-from=pieter.wuille@gmail.com;
helo=mail-ig0-f169.google.com;
Received: from mail-ig0-f169.google.com ([209.85.213.169])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X8Vtt-0003UI-9x
for bitcoin-development@lists.sourceforge.net;
Sat, 19 Jul 2014 14:46:14 +0000
Received: by mail-ig0-f169.google.com with SMTP id r2so1838023igi.4
for <bitcoin-development@lists.sourceforge.net>;
Sat, 19 Jul 2014 07:46:08 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.108.100 with SMTP id hj4mr20890447igb.43.1405781167986;
Sat, 19 Jul 2014 07:46:07 -0700 (PDT)
Received: by 10.50.161.137 with HTTP; Sat, 19 Jul 2014 07:46:07 -0700 (PDT)
Received: by 10.50.161.137 with HTTP; Sat, 19 Jul 2014 07:46:07 -0700 (PDT)
In-Reply-To: <CA+s+GJAd00ba7SzoUYeGvTOoHRiysXtYmx4Cnq8xQLXZx_VwyQ@mail.gmail.com>
References: <CAPg+sBiTURdRAZbyk3guF5YzAAQebo8yY_TuXHUKYDEdLjDUdQ@mail.gmail.com>
<CANEZrP3fA3gZ5u6yViBZpdTYxyFvZT=uOTDEnL797OueXf-16g@mail.gmail.com>
<CA+s+GJAd00ba7SzoUYeGvTOoHRiysXtYmx4Cnq8xQLXZx_VwyQ@mail.gmail.com>
Date: Sat, 19 Jul 2014 16:46:07 +0200
Message-ID: <CAPg+sBiUXuaSH8AAx2XzsvkDgzbE6Fz89jpx=y35vuRoezOU=w@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=089e01494c3c265f9f04fe8ceff3
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: 1X8Vtt-0003UI-9x
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Small update to BIP 62
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, 19 Jul 2014 14:46:14 -0000
--089e01494c3c265f9f04fe8ceff3
Content-Type: text/plain; charset=ISO-8859-1
On Jul 18, 2014 4:56 PM, "Wladimir" <laanwj@gmail.com> wrote:
>
> On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn <mike@plan99.net> wrote:
> > The rationale doesn't seem to apply to rule #4, what's so special about
that
> > one?
>
> > 4. Non-push operations in scriptSig Any non-push operation in a
scriptSig invalidates it.
>
> Having non-push operations in the scriptSig is a source of
> malleability, as there can be multiple sequences of opcodes that
> evaluate to the same result.
Well yes, but that is true for each of the rules and is already covered by
the previous specification in BIP62. Making it mandatory even for old
transaction does not really protect much against malleability as there are
several other sources of malleability that cannot be made mandatory in old
transactions left.
The reason for including #4 is just "allowing this does not benefit anyone".
--
Pieter
--089e01494c3c265f9f04fe8ceff3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On Jul 18, 2014 4:56 PM, "Wladimir" <<a href=3D=
"mailto:laanwj@gmail.com">laanwj@gmail.com</a>> wrote:<br>
><br>
> On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn <<a href=3D"mailto:mike=
@plan99.net">mike@plan99.net</a>> wrote:<br>
> > The rationale doesn't seem to apply to rule #4, what's so=
special about that<br>
> > one?<br>
><br>
> > 4. Non-push operations in scriptSig Any non-push operation in a s=
criptSig invalidates it.<br>
><br>
> Having non-push operations in the scriptSig is a source of<br>
> malleability, as there can be multiple sequences of opcodes that<br>
> evaluate to the same result.</p>
<p dir=3D"ltr">Well yes, but that is true for each of the rules and is alre=
ady covered by the previous specification in BIP62. Making it mandatory eve=
n for old transaction does not really protect much against malleability as =
there are several other sources of malleability that cannot be made mandato=
ry in old transactions left.</p>
<p dir=3D"ltr">The reason for including #4 is just "allowing this does=
not benefit anyone".</p>
<p dir=3D"ltr">-- <br>
Pieter</p>
--089e01494c3c265f9f04fe8ceff3--
|
