From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <freedom@reardencode.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 037C2C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 15:25:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id D833461002
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 15:25:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=reardencode.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id pmgJ89j0y-WQ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 15:25:11 +0000 (UTC)
X-Greylist: delayed 00:08:53 by SQLgrey-1.8.0
Received: from mail.reardencode.com (mail.reardencode.com [206.125.169.165])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 1B45E60FED
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 10 May 2022 15:25:11 +0000 (UTC)
Date: Tue, 10 May 2022 08:16:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reardencode.com;
 s=mail; t=1652195775;
 bh=p5eNLSX/v7bT2Gxi8yab4JtOlTReaKEaLwAwjhZIR+Y=;
 h=Date:From:To:Subject:References:In-Reply-To;
 b=b285jzSjjzjTzv66cRPNMJ/P1y8VQdvzYRG5FSXOiRjqpHHzaxpRcFAvIhATNGOvg
 nqQG9Qov9Xk5Kj3qthyf27QSeVJ4qvXFuoWA45XUa+l+51itYmJHDlKLXe6sLP8qI6
 3pTWdj53dEcTdgVucFOE1v0hmiYEH+tVOLd0lUyI=
From: Brandon Black <freedom@reardencode.com>
To: Rusty Russell <rusty@rustcorp.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <YnqBuhbUGKmT+NW8@console>
Mail-Followup-To: Rusty Russell <rusty@rustcorp.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <87h75xoet1.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87h75xoet1.fsf@rustcorp.com.au>
X-Operating-System: Linux 5.10.93 x86_64
X-Mailman-Approved-At: Tue, 10 May 2022 15:35:06 +0000
Subject: Re: [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced
 to OP_CHECKTEMPLATEVERIFY
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Tue, 10 May 2022 15:25:13 -0000

Hi Rusty,

Thanks for this. Seems like a productive direction to explore.

To me, one of the biggest limitations of CTV is that the script is
specific to the amount of the input being spent. OP_TX makes it
possible, although clumsy, to emulate OP_IN_OUT_AMOUNT, which could be
combined with CTV emulation less OPTX_SELECT_OUTPUT_AMOUNT32x2 to allow
a single script to be reused. Given that potential, I wonder if
OPTX_SELECT_IN_OUT_AMOUNT32x2 would be worth adding to the initial set
of flags.

With that addition, a small script can be constructed for a relocatable,
batchable construction (eg. as a building block for vaults):

OPTX_SEPARATELY|OPTX_UNHASHED|OPTX_INPUTNUM OP_TX OP_DUP

OPTX_SELECT_VERSION|
OPTX_SELECT_LOCKTIME|
OPTX_SELECT_INPUT_SINGLE|
OPTX_SELECT_INPUT_SCRIPT|
OPTX_SELECT_INPUT_NSEQUENCE|
OPTX_SELECT_OUTPUT_SINGLE|
OPTX_SELECT_OUTPUT_SCRIPTPUBKEY|
OPTX_SELECT_IN_OUT_AMOUNT32x2 OP_TX <expectedhash> OP_EQUAL

* Additional inputs and change outputs can be added
  * Could commit to 0 fee and still be useful
* Arbitrary amounts can be sent to the same script
* There is no txid predictability (unlike CTV)
  * Anyone could rearrange such input/output pairs after broadcast
	* Not suitable for some uses
	* Potentially helpful for others

Best,

--Brandon

On 2022-05-10 (Tue) at 20:05:54 +0930, Rusty Russell via bitcoin-dev wrote:
> Hi all,
> 
> 	TL;DR: a v1 tapscript opcode for generic covenants, but
> OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY.  This gives an
> obvious use case, with clean future expansion.  OP_NOP4 can be
> repurposed in future as a shortcut, if experience shows that to be a
> useful optimization.
> 
> (This proposal builds on Russell O'Connor's TXHASH[1], with Anthony
> Towns' modification via extending the opcode[2]; I also notice on
> re-reading that James Lu had a similar restriction idea[3]).
> 
> Details
> -------
> 
> OP_TX, when inside v1 tapscript, is followed by 4 bytes of flags.
> Unknown flag patterns are OP_SUCCESS, though for thoroughness some future
> potential uses are documented here.  Note that pushing more than 1000
> elements on the stack or an element more than 512 bytes will hit the
> BIP-342 resource limits and fail.
> 
> Defined bits
> ------------
> 
> (Only those marked with * have to be defined for this soft fork; the
>  others can have semantics later).
> 
> OPTX_SEPARATELY: treat fields separately (vs concatenating)
> OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push)
> 
> - The first nicely sidesteps the lack of OP_CAT, and the latter allows
>   OP_TXHASH semantics (and avoid stack element limits).
> 
> OPTX_SELECT_VERSION*: version
> OPTX_SELECT_LOCKTIME*: nLocktime
> OPTX_SELECT_INPUTNUM*: current input number
> OPTX_SELECT_INPUTCOUNT*: number of inputs
> OPTX_SELECT_OUTPUTCOUNT*: number of outputs
> 
> OPTX_INPUT_SINGLE: if set, pop input number off stack to apply to
> 		OPTX_SELECT_INPUT_*, otherwise iterate through all.
> OPTX_SELECT_INPUT_TXID: txid
> OPTX_SELECT_INPUT_OUTNUM: txout index
> OPTX_SELECT_INPUT_NSEQUENCE*: sequence number
> OPTX_SELECT_INPUT_AMOUNT32x2: sats in, as a high-low u31 pair
> OPTX_SELECT_INPUT_SCRIPT*: input scriptsig
> OPTX_SELECT_INPUT_TAPBRANCH: ?
> OPTX_SELECT_INPUT_TAPLEAF: ?
> 
> OPTX_OUTPUT_SINGLE: if set, pop input number off stack to apply to
> 		OPTX_SELECT_OUTPUT_*, otherwise iterate through all.
> OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair
> OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey
> 
> OPTX_SELECT_19...OPTX_SELECT_31: future expansion.
> 
> OP_CHECKTEMPLATEVERIFY is approximated by the following flags:
> 	OPTX_SELECT_VERSION
> 	OPTX_SELECT_LOCKTIME
> 	OPTX_SELECT_INPUTCOUNT
> 	OPTX_SELECT_INPUT_SCRIPT
> 	OPTX_SELECT_INPUT_NSEQUENCE
> 	OPTX_SELECT_OUTPUTCOUNT
> 	OPTX_SELECT_OUTPUT_AMOUNT32x2
> 	OPTX_SELECT_OUTPUT_SCRIPTPUBKEY
> 	OPTX_SELECT_INPUTNUM
> 
> All other flag combinations result in OP_SUCCESS.
> 
> Discussion
> ----------
> 
> By enumerating exactly what can be committed to, it's absolutely clear
> what is and isn't committed (and what you need to think about!).
> 
> The bits which separate concatenation and hashing provide a simple
> mechanism for template-style (i.e. CTV-style) commitments, or for
> programatic treatment of individual elements (e.g. amounts, though the
> two s31 style is awkward: a 64-bit push flag could be added in future).
> 
> The lack of double-hashing of scriptsigs and other fields means we
> cannot simply re-use hashing done for SIGHASH_ALL.
> 
> The OP_SUCCESS semantic is only valid in tapscript v1, so this does not
> allow covenants for v0 segwit or pre-segwit inputs.  If covenants prove
> useful, dedicated opcodes can be provided for those cases (a-la
> OP_CHECKTEMPLATEVERIFY).
> 
> Cheers,
> Rusty.
> 
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019819.html
> [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019816.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
--Brandon