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
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1XdxAN-00053o-2h
for bitcoin-development@lists.sourceforge.net;
Tue, 14 Oct 2014 08:09:11 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.109 as permitted sender)
client-ip=62.13.148.109; envelope-from=pete@petertodd.org;
helo=outmail148109.authsmtp.co.uk;
Received: from outmail148109.authsmtp.co.uk ([62.13.148.109])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1XdxAH-0000c3-AF for bitcoin-development@lists.sourceforge.net;
Tue, 14 Oct 2014 08:09:11 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s9E88waS024663;
Tue, 14 Oct 2014 09:08:58 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s9E88ruG071579
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 14 Oct 2014 09:08:55 +0100 (BST)
Date: Tue, 14 Oct 2014 04:09:05 -0400
From: Peter Todd <pete@petertodd.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20141014080905.GA10545@savin.petertodd.org>
References: <CAPg+sBjbeAaTmEvqrHHU4Mb45VPyRvFxdRzz1S6+-t7ep20ZtQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO"
Content-Disposition: inline
In-Reply-To: <CAPg+sBjbeAaTmEvqrHHU4Mb45VPyRvFxdRzz1S6+-t7ep20ZtQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 582bfff1-5379-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwYUF1YAAgsB AmIbW11eUFV7XGU7 bA9PbARUfEhLXhtr
VklWR1pVCwQmQhV0 DhZcF25ycARDf3c+ ZEdmXnAVWUx4JxAr
FE9JEG4BbHphaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDOzc4 Qx0LFzEiVUcCQCE+ Jho9Ql4B
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [62.13.148.109 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1XdxAH-0000c3-AF
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Malleable booleans
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: Tue, 14 Oct 2014 08:09:11 -0000
--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Oct 13, 2014 at 07:34:16PM -0700, Pieter Wuille wrote:
> Hi all,
>=20
> while working on a BIP62 implementation I discovered yet another type
> of malleability: the interpretation of booleans.
>=20
> Any byte array with non-zero bytes in it (ignoring the highest bit of
> the last byte, which is the sign bit when interpreting as a number) is
> interpreted as true, anything else as false. Other than numbers,
> they're not even restricted to 4 bytes. Worse, the code for dealing
> with booleans is not very consistent: OP_BOOLAND and OP_BOOLOR first
> interpret their arguments as numbers, and then compare them to 0 to
> turn them into boolean values.
>=20
> This means that scripts that use booleans as inputs will be inherently
> malleable. Given that that seems actually useful (passing in booleans
> to guide some OP_IF's during execution of several alternatives), I
> would like to change BIP62 to also state that interpreted booleans
> must be of minimal encoded size (in addition to numbers).
>=20
> Any opinions for or against?
I noticed this awhile back myself. More interestingly, I remember
noticing some non-std scripts on mainnet that had opcodes that appeared
to be attempts to solve this issue with variations of the following:
DUP
IF
1 EQUALVERIFY
<do stuff>
ELSE
0 EQUALVERIFY
<do stuff>
ENDIF
I'll have to admit, I decided to keep quiet about it because it's a good
example of how relying on BIP62 for specialty contract applications that
absolutely need to avoid malleability for security reasons is a dubious
idea; it's hard to be sure that we've really gotten every relevant case
correct.
I think a decent argument *for* doing this is that if a script author
fails to properly 'bool-ize' every boolean-using path that can have
non-minimal encodings in normal execution, you can always create a
nVersion=3D1 transaction manually to spend the output, preventing funds
=66rom getting lost. Meanwhile in the general case of a compenent script
author having the canonical bool testing in every boolean-using opcode
saves a lot of bytes.
--=20
'peter'[:-1]@petertodd.org
0000000000000000147fe2005d7d4490938a7ab96901b8256dcd9d4eac78cb8c
--2oS5YaxWCcQjTEyO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJUPNoaXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxNjZjYjg4NTliZGUwMjk0YzU1MGJiMDkwM2Y1YTExNWE2
MjBjNmExYzQxZGNkOGYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftxLgf8Cu3ZRTnpweU1qPR0dDVAQYjD
NvZQtidHI0JATnbXEEU+dSsbjGf0ukEB8Ke9jaXZJK9EooZ3lY8mv+/eEiY51ezT
8PL4/4ZczMckKoX7X3mI4KvjVy7iybPnVzHEgUzRPvGE05WxFnPXTqdAlefStpdy
XNbLNVNM4Bj51aqUFl3z4i+6C46i+S89gGqocbRIb948wPDEiXMNhr6A5gutC+Gj
e2QFSS4XSztZfBOOpb6zjUF1DQbSWfWvMxXJRphHUoRf1CzSeJHCif7F/3y1cYRw
sHOYEUaqCWmXeWF9o2adyFnoesIa70oPr/ZxIw6kZ7XNyUPecoxMg3AzMKeIXQ==
=/2Cf
-----END PGP SIGNATURE-----
--2oS5YaxWCcQjTEyO--
|
