Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0EB2F15
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 23 Dec 2018 04:27:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6BFE8A8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 23 Dec 2018 04:27:18 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
	by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
	id 1gavLz-0001zi-It; Sun, 23 Dec 2018 14:27:05 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
	Sun, 23 Dec 2018 14:26:59 +1000
Date: Sun, 23 Dec 2018 14:26:59 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Johnson Lau <jl2012@xbt.hk>
Message-ID: <20181223042659.munrqfe4l6nff2ug@erisian.com.au>
References: <87ftv3xerx.fsf@rustcorp.com.au>
	<DAAB7568-A004-4897-B5B3-0FBBC6895246@xbt.hk>
	<87pnu6s3v5.fsf@rustcorp.com.au> <87h8fiqn1z.fsf@rustcorp.com.au>
	<20181214093002.p2nvfrlaycqblww3@erisian.com.au>
	<F9FE2267-0BCB-4C67-9AE8-3285B7459D51@xbt.hk>
	<87mup4hmq5.fsf@rustcorp.com.au>
	<2302A26C-FB9C-47D2-AF6C-4D2EF02FFAC0@xbt.hk>
	<87y38jn5z8.fsf@rustcorp.com.au>
	<73F32BC6-751E-4F35-BE6D-B31170FC0A54@xbt.hk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <73F32BC6-751E-4F35-BE6D-B31170FC0A54@xbt.hk>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
	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: Sun, 23 Dec 2018 18:43:54 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Dec 2018 04:27:19 -0000

On Sat, Dec 22, 2018 at 02:54:42AM +0800, Johnson Lau wrote:
> The question I would like to ask is: is OP_CODESEPARATOR useful under taproot? Generally speaking, CODESEPARATOR is useful only with conditional opcodes (OP_IF etc), and conditional opcodes are mostly replaced by merklized scripts. I am not sure how much usability is left with CODESEPARATOR

If you don't have conditionals, then I think committing to the (masked)
script gives you everything you could do with codeseparator.

If you don't commit to the (masked) script, don't have conditionals,
and don't have codeseparator, then I don't think you can make a signature
distinguish which alternative script it's intending to sign; but you can
just give each alternative script in the MAST a slight variation of the
key and that seems good enough.

OTOH, I think for (roughly) the example you gave:

  DEPTH 3 EQUAL
  IF <Bob> CHECKSIGVERIFY HASH160 <H> EQUALVERIFY CODESEP
  ELSE <n> CLTV DROP
  ENDIF
  <Alice> CHECKSIG

then compared to the taproot equivalent:

  P = muSig(Alice,Bob)
  S1 = <Alice1> CHECKSIGVERIFY <Bob> CHECKSIGVERIFY HASH160 <H> EQUAL
  S2 = <Alice2> CHECKSIGVERIFY <n> CLTV

the IF+CODESEP approach is actually cheaper (lighter weight) if you're
mostly (>2/3rds of the time) taking the S1 branch. This is because the
"DEPTH 3 EQUAL IF/ELSE/ENDIF CODESEP <n> CLTV DROP" overhead is less
than the 32B overhead to choose a merkle branch).

(That said, I'm not sure what Alice's signature in the S1 branch actually
achieves in that script; and without that in S1, the taproot approach is
cheaper all the time. Scriptless scripts would be cheaper still)

> If no one needs CODESEPARATOR, we might just disable it, and makes the validation code a bit simpler

Since it only affects the behaviour of the checkdls (checksig) operators,
even if it was disabled, it could be re-enabled fairly easily in a new
script subversion if needed (ie, it could be re-added when upgrading
witness version 1 from script version 0 to 1).

Cheers,
aj