Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xe81z-0007b3-KA for bitcoin-development@lists.sourceforge.net; Tue, 14 Oct 2014 19:45:15 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.98 as permitted sender) client-ip=62.13.148.98; envelope-from=pete@petertodd.org; helo=outmail148098.authsmtp.com; Received: from outmail148098.authsmtp.com ([62.13.148.98]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Xe81x-00049d-9P for bitcoin-development@lists.sourceforge.net; Tue, 14 Oct 2014 19:45:15 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s9EJj6j0085288; Tue, 14 Oct 2014 20:45:06 +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 s9EJj26g092180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 14 Oct 2014 20:45:04 +0100 (BST) Date: Tue, 14 Oct 2014 15:45:18 -0400 From: Peter Todd To: Pieter Wuille Message-ID: <20141014194518.GB941@savin.petertodd.org> References: <20141014080905.GA10545@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 984760fb-53da-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwYUF1YAAgsB AmIbWVReVFh7WWY7 bA9PbARUfEhLXhtr VklWR1pVCwQmQhV0 fEQcVE5yfgdHcH4+ bERlXT5SVEB9c0Yr EFNRFjlXeGZhPWQC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4uFzo4 ShkIGThnF0oCQyg6 KQdO 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Xe81x-00049d-9P 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 19:45:15 -0000 --l76fUT7nc3MelDdI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 14, 2014 at 11:54:36AM -0700, Pieter Wuille wrote: > > 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 > > from 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 > The real question is whether there are use cases for not having this > requirement. I can't come up with any, as that would imply a boolean > that is also interpretable as a hash, a pubkey or a signature - all of > which seems crpytographically impossible to ever result in false. I'm kinda inclined to agree, however there is an opposing argument too: How often is BOOLAND and BOOLOR applied to unsanitised input from the scriptSig? I can't think of a script type where that would be the case, unlike OP_IF where the logical way of writing scripts is to have the scriptSig select which brance you take. In every script I've ever thought of BOOLAND and BOOLOR is applied to stuff generated within the script itself, which isn't a malleability concern. --=20 'peter'[:-1]@petertodd.org 000000000000000005f3f265a1636bd90c2c8098093c2db2ccfc91c17890a714 --l76fUT7nc3MelDdI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJUPX1JXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwNWYzZjI2NWExNjM2YmQ5MGMyYzgwOTgwOTNjMmRiMmNj ZmM5MWMxNzg5MGE3MTQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvwyAf9H08NNHCbbcGE/OpFdgZoWYGU g8sA0DCzq4wr3Z0fjU4frv4b2TiUkCkbJ6mmE/N5RgDH1syqmzpmr0OWLHG+kN63 SJUxd4YHtC+b9SD75cz8C6kWGCNurxASElWERRYrVTO5nWR0XK4CIZHm6ZVm0BQ0 xHFXyQ6zmOPlGtwXIVjEhfGFdpv7y1gkMaP4uGgryLhEeUOOHfJgYG8djyLGV9XE Hehj3vt/zUOxMnLlk9phMlPJfD6qwA4IiGe4mUxORzh/0YGWZ84KaIhR0nZOGa0N JDUncDX/aOGxYwDmKb6kFZu9oXtTCNqd8gNiVUYeP7uJWir8MmN7b3IzFO+SMQ== =5LVR -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI--