Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B9E7F8EF for ; Tue, 10 Nov 2015 10:52:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E0F63138 for ; Tue, 10 Nov 2015 10:52:49 +0000 (UTC) Received: by wmec201 with SMTP id c201so108525011wme.1 for ; Tue, 10 Nov 2015 02:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=DCu73m7dl86CFgPUW3K6RhVlIttdPJqag/1CkcWfTbo=; b=AYYEFFZmlmKU6x4Agwjz3QqhejoQCGZgDFLd64Qu7XwPTUF2VNGacK7jUmaWLBfWBO sbKQcQlp6Sg620MUwZO9CJwbjuLeLfUGQl89jCFxYV3j3EttVQbVuzgG4vSyNho6SYcb xNSgLtCgoOUrER8kk1aC+e2YAePfxPvS1K8kShV7cYl3h6qP1u0wL+rtYrRt0MQ9fUfm aSgv+3k3r6blAu4Hi8AxobDAHbQpPX9vFHCC6GBG+QXwxIZRp1nERkeTcDS49JeHzDFx 1nMBUBnMxPImcy9F6hKlohG/fpM2Zs7tqq5/YmI87w2v6Qak/8OgcpQYLcIUaYUBXyZp 00SA== X-Received: by 10.28.20.139 with SMTP id 133mr33427611wmu.36.1447152768379; Tue, 10 Nov 2015 02:52:48 -0800 (PST) Received: from [10.0.1.5] (AStLambert-651-1-41-45.w90-43.abo.wanadoo.fr. [90.43.88.45]) by smtp.gmail.com with ESMTPSA id u139sm6809062wmu.22.2015.11.10.02.52.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Nov 2015 02:52:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1CD79689-9A75-4F5F-8DA7-189F62CD918F" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Oleg Andreev In-Reply-To: Date: Tue, 10 Nov 2015 11:52:46 +0100 Message-Id: References: <0e72b173ea8e8aaf6b1b678182fa1ea7@xbt.hk> <8D9D1049-E502-4A37-ACE4-5A2B1369A90A@gmail.com> To: Tier Nolan X-Mailer: Apple Mail (2.3096.5) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Dealing with OP_IF and OP_NOTIF malleability X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 10:52:50 -0000 --Apple-Mail=_1CD79689-9A75-4F5F-8DA7-189F62CD918F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii OP_0 gives a zero length byte array because OP_0 =3D=3D 0x00 which is = equivalent to pushdata with zero length. OP_EQUAL compares byte strings as-is. So it will push "false" because = empty string is not the same as a single-byte string with 0x00 byte in = it. Value "false" in turn is encoded as empty string, just like result = of OP_0. > On 06 Nov 2015, at 10:37, Tier Nolan via bitcoin-dev = wrote: >=20 > I meant not to use the OP_PUSH opcodes to do the push. >=20 > Does OP_0 give a zero length byte array? >=20 > Would this script return true? >=20 > OP_0 > OP_PUSHDATA1 (length =3D 1, data =3D 0) > OP_EQUAL >=20 > The easiest definition is that OP_0 and OP_1 must be used to push the = data and not any other push opcodes. >=20 >=20 > On Fri, Nov 6, 2015 at 9:32 AM, Oleg Andreev > wrote: >=20 > > One and zero should be defined as arrays of length one. Otherwise, = it is still possible to mutate the transaction by changing the length of = the array. > > > > They should also be minimally encoded but that is covered by = previous rules. >=20 > These two lines contradict each other. Minimally-encoded "zero" is an = array of length zero, not one. I'd suggest defining this explicitly here = as "IF/NOTIF argument must be either zero-length array or a single byte = 0x01". >=20 >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_1CD79689-9A75-4F5F-8DA7-189F62CD918F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii OP_0 gives a zero length byte array because OP_0 =3D=3D 0x00 = which is equivalent to pushdata with zero length.

OP_EQUAL compares byte strings as-is. = So it will push "false" because empty string is not the same as a = single-byte string with 0x00 byte in it. Value "false" in turn is = encoded as empty string, just like result of OP_0.

On 06 Nov 2015, at 10:37, Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

I meant not to use the OP_PUSH opcodes to do = the push.

Does OP_0 = give a zero length byte array?

Would this script return true?

OP_0
OP_PUSHDATA1 (length =3D 1, data =3D 0)
OP_EQUAL

The easiest definition is that OP_0 and = OP_1 must be used to push the data and not any other push opcodes.


On Fri, Nov 6, 2015 at 9:32 AM, = Oleg Andreev <oleganza@gmail.com> wrote:

> One and zero should be defined as arrays of length one. Otherwise, = it is still possible to mutate the transaction by changing the length of = the array.
>
> They should also be minimally encoded but that is covered by = previous rules.

These two lines contradict each other. Minimally-encoded "zero" = is an array of length zero, not one. I'd suggest defining this = explicitly here as "IF/NOTIF argument must be either zero-length array = or a single byte 0x01".



_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_1CD79689-9A75-4F5F-8DA7-189F62CD918F--