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