From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Pieter Wuille Message-ID: <20141014080905.GA10545@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: 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 Subject: Re: [Bitcoin-development] Malleable booleans 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: 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 ELSE 0 EQUALVERIFY 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--