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 C94F0C00
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Jun 2019 22:06:05 +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 417D6E6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Jun 2019 22:06:05 +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 1he5Bt-00052c-Kl; Fri, 21 Jun 2019 08:05:59 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
	Fri, 21 Jun 2019 08:05:52 +1000
Date: Fri, 21 Jun 2019 08:05:52 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.io>
Message-ID: <20190620220552.metrqaul3iporwma@erisian.com.au>
References: <CAD5xwhjSj82YYuQHHbwgSLvUNV2RDY0b=yMYeLj-p6j7PpS9-Q@mail.gmail.com>
	<20190605093039.xfo7lcylqkhsfncv@erisian.com.au>
	<im0q8670MxshmvMLmoJU0dv4rFhwWZNvQeQYv7i4fBWJOx0ghAdH8fYuQSqNxO2z8uxXGV-kurinUDfl0FsLWD0knw_U_h3zVZ0xy7vmn8o=@protonmail.com>
	<CAMZUoK=ZB06jwAbuX2D=aN8ztAqr_jSgEXS1z1ABjQYVawKCBQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMZUoK=ZB06jwAbuX2D=aN8ztAqr_jSgEXS1z1ABjQYVawKCBQ@mail.gmail.com>
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: Fri, 21 Jun 2019 17:31:27 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)
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: Thu, 20 Jun 2019 22:06:05 -0000

On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote:
> So with regards to OP_SECURETHEBAG, I am also "not really seeing any reason to
> complicate the spec to ensure the digest is precommitted as part of the
> opcode."

Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT
(NOINPUT) sighash (Johnson Lau's mentioned this before, but not sure if
it's been spelled out anywhere); ie instead of constructing

  X = Hash_BagHash( version, locktime, [outputs], [sequences], num_in )

and having the script be "<X> OP_SECURETHEBAG" you calculate an
ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL:

  Y = Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0,
                       amount, sequence)

and calculate a signature sig = Schnorr(P,m) for some pubkey P, and
make your script be "<sig> <P> CHECKSIG".

That loses the ability to commit to the number of inputs or restrict
the nsequence of other inputs, and requires a bigger script (sig and P
are ~96 bytes instead of X's 32 bytes), but is otherwise pretty much the
same as far as I can tell. Both scripts are automatically satisfied when
revealed (with the correct set of outputs), and don't need any additional
witness data.

If you wanted to construct "X" via script instead of hardcoding a value
because it got you generalised covenants or whatever; I think you could
get the same effect with CAT,LEFT, and RIGHT: you'd construct Y in much
the same way you construct X, but you'd then need to turn that into a
signature. You could do so by using pubkey P=G and nonce R=G, which
means you need to calculate s=1+hash(G,G,Y)*1 -- calculating the hash
part is easy, multiplying it by 1 is easy, and to add 1 you can probably
do something along the lines of:

    OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT

(ie, take the last 4 bytes, increment it using 4-byte arithmetic,
then cat the first 28 bytes and the result. There's overflow issues,
but I think they can be worked around either by allowing you to choose
different locktimes, or by more complicated script)

Cheers,
aj