Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 98C37CF7 for ; Thu, 22 Nov 2018 14:28:47 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D5EF7771 for ; Thu, 22 Nov 2018 14:28:46 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1542896924; cv=none; d=zoho.com; s=zohoarc; b=MIB5SmmZCG1JN6bHqtfG3QwTdrBsvanTbF9wc2htnIZlB4w97b4WsLPOaaKahKrLfQDpq7gQe+0b4vVl4mt6mlNyb6zKC2MgfyZEXMoAHVgioKAiiPdyhOAuX9rv1usKU5G2XkM11aTpaOtfF9NgwqX00SsHwRHjNRYVrhgD8Vo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1542896924; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=31yLSRAwcm9dfl+YUFy99h1A1fsQe/1LEoIt+0Psmyw=; b=ZGiyPIRQpR3Czl2h16URwP4i9cvgyemX2C80AWavug0LggWCGM8xxwAc6DeJF8ncyp//CvumfYkUf1ITktDso+QJHrmcZoAr04hXmC9lrmFaWM9Hc1aOJdaTivjMCvCuftps77aOmIjS9J5U4vmoYAJvNcqbnvRI3b9GiutQIlk= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk; spf=pass smtp.mailfrom=jl2012@xbt.hk; dmarc=pass header.from= header.from= Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118]) by mx.zohomail.com with SMTPS id 1542896921764887.5171324645357; Thu, 22 Nov 2018 06:28:41 -0800 (PST) From: Johnson Lau Message-Id: <64A86A3A-4633-4BE2-AE09-30BD136BCC2D@xbt.hk> Content-Type: multipart/alternative; boundary="Apple-Mail=_2A279FC6-858D-4FAB-9E82-126628860469" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Thu, 22 Nov 2018 22:28:35 +0800 In-Reply-To: To: Russell O'Connor , bitcoin-dev References: X-Mailer: Apple Mail (2.3445.100.39) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 23 Nov 2018 04:04:44 +0000 Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 14:28:47 -0000 --Apple-Mail=_2A279FC6-858D-4FAB-9E82-126628860469 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii With MAST in taproot, OP_IF etc become mostly redundant, with worse = privacy. To maximise fungibility, we should encourage people to use = MAST, instead of improve the functionality of OP_IF and further = complicate the protocol. > On 22 Nov 2018, at 1:07 AM, Russell O'Connor via bitcoin-dev = wrote: >=20 > On Mon, Nov 19, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev = > wrote: > So my question is whether anyone can see ways in which this introduces > redundant flexibility, or misses obvious use cases? >=20 > Hopefully my comment is on-topic for this thread: >=20 > Given that we want to move away from OP_CODESEPARATOR, because each = call to this operation effectively takes O(script-size) time, we need a = replacement for the functionality it currently provides. While perhaps = the original motivation for OP_CODESEPARTOR is surrounded in mystery, it = currently can be used (or perhaps abused) for the task of creating = signature that covers, not only which input is being signed, but which = specific branch within that input Script code is being signed for. >=20 > For example, one can place an OP_CODESEPARATOR within each branch of = an IF block, or by placing an OP_CODESEPARATOR before each OP_CHECKSIG = operation. By doing so, signatures created for one clause cannot be = used as signatures for another clause. Since different clauses in = Bitcoin Script may be enforcing different conditions (such as different = time-locks, hash-locks, etc), it is useful to be able to sign in such a = way that your signature is only valid when the conditions for a = particular branch are satisfied. In complex Scripts, it may not be = practical or possible to use different public keys for every different = clause. (In practice, you will be able to get away with fewer = OP_CODESEPARATORS than one in every IF block). >=20 > One suggestion I heard (I think I heard it from Pieter) to achieve the = above is to add an internal counter that increments on every control = flow operator, OP_IF, OP_NOTIF, OP_ELSE, OP_ENDIF, and have the = signature cover the value of this counter. Equivalently we divide every = Bitcoin Script program into blocks deliminated by these control flow = operator and have the signature cover the index of the block that the = OP_CHECKSIG occurs within. More specifically, we will want a SigHash = flag to enables/disable the signature covering this counter. >=20 > There are many different ways one might go about replacing the = remaining useful behaviour of OP_CODESEPARATOR than the one I gave = above. I would be happy with any solution. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_2A279FC6-858D-4FAB-9E82-126628860469 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii With = MAST in taproot, OP_IF etc become mostly redundant, with worse privacy. = To maximise fungibility, we should encourage people to use MAST, instead = of improve the functionality of OP_IF and further complicate the = protocol.


On 22 = Nov 2018, at 1:07 AM, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On = Mon, Nov 19, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
So my question is = whether anyone can see ways in which this introduces
redundant flexibility, or misses obvious use cases?

Hopefully my comment is on-topic for this thread:

Given that we want to = move away from OP_CODESEPARATOR, because each call to this operation = effectively takes O(script-size) time, we need a replacement for the = functionality it currently provides.  While perhaps the original = motivation for OP_CODESEPARTOR is surrounded in mystery, it currently = can be used (or perhaps abused) for the task of creating signature that = covers, not only which input is being signed, but which specific branch = within that input Script code is being signed for.

For example, one can = place an OP_CODESEPARATOR within each branch of an IF block, or by = placing an OP_CODESEPARATOR before each OP_CHECKSIG operation.  By = doing so, signatures created for one clause cannot be used as signatures = for another clause.  Since different clauses in Bitcoin Script may = be enforcing different conditions (such as different time-locks, = hash-locks, etc), it is useful to be able to sign in such a way that = your signature is only valid when the conditions for a particular branch = are satisfied.  In complex Scripts, it may not be practical or = possible to use different public keys for every different clause. (In = practice, you will be able to get away with fewer OP_CODESEPARATORS than = one in every IF block).

One suggestion I heard (I think I heard = it from Pieter) to achieve the above is to add an internal counter that = increments on every control flow operator, OP_IF, OP_NOTIF, OP_ELSE, = OP_ENDIF, and have the signature cover the value of this counter.  = Equivalently we divide every Bitcoin Script program into blocks = deliminated by these control flow operator and have the signature cover = the index of the block that the OP_CHECKSIG occurs within.  More = specifically, we will want a SigHash flag to enables/disable the = signature covering this counter.

There are many different ways one might = go about replacing the remaining useful behaviour of OP_CODESEPARATOR = than the one I gave above. I would be happy with any solution.
_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_2A279FC6-858D-4FAB-9E82-126628860469--