Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1CAC0C000B for ; Tue, 8 Feb 2022 04:34:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id F3F758131F for ; Tue, 8 Feb 2022 04:34:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYtzRqoOkhI9 for ; Tue, 8 Feb 2022 04:34:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by smtp1.osuosl.org (Postfix) with ESMTPS id 7CC968131E for ; Tue, 8 Feb 2022 04:34:44 +0000 (UTC) Received: by mail-lf1-x12f.google.com with SMTP id f10so30904428lfu.8 for ; Mon, 07 Feb 2022 20:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vcLERYvxxfbTmNSm872SoMEJhODJ9ExlXbBFUs10vKk=; b=Y/b3iLvyHrIByLwaJ5Hif/PLIeRum5kOP2OpVirchJwNnImITdM+yHbFlHyr6pX/Ec 5SqhZqX4XQ9764hnQEe+6cgt92Rd4CQ4+rBU0v8nFOM6Y9YpdNqmsm+POBQL9e1a41BU Tua5xbK0CI96ipCJ+liyrdWnyD0ZpLjE097YfevEV2VEJpZjcCMPPiELOjJuxe4UTdAy q+dmXImLrGUdyKdT27AnjO8+CTKWGW+J/q9e4wVuNPj5BlJNDdWtYS4o5p2LiCWt/Myi /+W6QQeKOo2sIUoJa3A8wtPwmV94UkiYA18FLJVrDSjBJX8o0t9AsvnVRlw/MvI4rxIv t0ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vcLERYvxxfbTmNSm872SoMEJhODJ9ExlXbBFUs10vKk=; b=3a6HtOPmLSHYdRSRgGO71KTLf33IKs/GaXsMl1OxMYh9mmK7msneDOVNfZXtLjgRil 5zdJ0E0jtD5pQtO1EhTWe/xDX8SOBE8OPhS9Yw5u2MpelwkDxYoQA7Z6S2jCy/VlsVKh gTMa+GHbsL1QnQgH2YOg35Tl+KU0Hktg3xW5iSF/1mf9e07679E67LsSdJUeNvDcI7HL xsS90eTp9++pdfZ6R2UyXYuqmhZlHLfhrJVhC6ojseKlX4xsalv3n1RRA9sLWFSIs6uV PlIyJ0yB/l1gXd6Yc3SJ8QLyxYNBz1Mjj6YXtceSpZcVqMCmcGGgzCXEdBUVYtfij8zb oA0w== X-Gm-Message-State: AOAM530c6Jzu6Ij/ugz6J6wXdoYYQJXjLojlIeU38sNV8d1uH8R7qBx7 ierzZIq03gxyyXUDGdlunag50G4yzVM+WbZ0k48= X-Google-Smtp-Source: ABdhPJxDH3Odr3tZ0oVTkE6uAnd3n8ZV8ovwaBCqrhQ7ypojSsQiSqihXLAy3dM2f+5Krm0SoL2SblXycA15KCms9xQ= X-Received: by 2002:a05:6512:31d3:: with SMTP id j19mr2014130lfe.112.1644294881882; Mon, 07 Feb 2022 20:34:41 -0800 (PST) MIME-Version: 1.0 References: <87leymuiu8.fsf@rustcorp.com.au> In-Reply-To: <87leymuiu8.fsf@rustcorp.com.au> From: Jeremy Rubin Date: Mon, 7 Feb 2022 20:34:30 -0800 Message-ID: To: Rusty Russell , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000005733ef05d77a3c84" Subject: Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2022 04:34:46 -0000 --0000000000005733ef05d77a3c84 Content-Type: text/plain; charset="UTF-8" Rusty, Note that this sort of design introduces recursive covenants similarly to how I described above. Whether that is an issue or not precluding this sort of design or not, I defer to others. Best, Jeremy On Mon, Feb 7, 2022 at 7:57 PM Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Russell O'Connor via bitcoin-dev > writes: > > Given the overlap in functionality between CTV and ANYPREVOUT, I think it > > makes sense to decompose their operations into their constituent pieces > and > > reassemble their behaviour programmatically. To this end, I'd like to > > instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY. > > > > OP_TXHASH would pop a txhash flag from the stack and compute a (tagged) > > txhash in accordance with that flag, and push the resulting hash onto the > > stack. > > It may be worth noting that OP_TXHASH can be further decomposed into > OP_TX (and OP_TAGGEDHASH, or just reuse OP_SHA256). > > OP_TX would place the concatenated selected fields onto the stack > (rather than hashing them) This is more compact for some tests > (e.g. testing tx version for 2 is "OP_TX(version) 1 OP_EQUALS" vs > "OP_TXHASH(version) 012345678...aabbccddeeff OP_EQUALS"), and also range > testing (e.g amount less than X or greater than X, or less than 3 inputs). > > > I believe the difficulties with upgrading TXHASH can be mitigated by > > designing a robust set of TXHASH flags from the start. For example > having > > bits to control whether (1) the version is covered; (2) the locktime is > > covered; (3) txids are covered; (4) sequence numbers are covered; (5) > input > > amounts are covered; (6) input scriptpubkeys are covered; (7) number of > > inputs is covered; (8) output amounts are covered; (9) output > scriptpubkeys > > are covered; (10) number of outputs is covered; (11) the tapbranch is > > covered; (12) the tapleaf is covered; (13) the opseparator value is > > covered; (14) whether all, one, or no inputs are covered; (15) whether > all, > > one or no outputs are covered; (16) whether the one input position is > > covered; (17) whether the one output position is covered; (18) whether > the > > sighash flags are covered or not (note: whether or not the sighash flags > > are or are not covered must itself be covered). Possibly specifying > which > > input or output position is covered in the single case and whether the > > position is relative to the input's position or is an absolute position. > > These easily map onto OP_TX, "(1) the version is pushed as u32, (2) the > locktime is pushed as u32, ...". > > We might want to push SHA256() of scripts instead of scripts themselves, > to reduce possibility of DoS. > > I suggest, also, that 14 (and similarly 15) be defined two bits: > 00 - no inputs > 01 - all inputs > 10 - current input > 11 - pop number from stack, fail if >= number of inputs or no stack elems. > > Cheers, > Rusty. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000005733ef05d77a3c84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rusty,

Note that this= sort of design introduces recursive covenants similarly to how I described= above.

Whether that is an issue or not precluding this sort of= design or not, I defer to others.

Best,

Jeremy


On Mon, Feb 7, 2022 at 7:57 PM Rusty Russell via bitcoin-dev <bitcoin-dev@lists.lin= uxfoundation.org> wrote:
Russell O'Con= nor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> write= s:
> Given the overlap in functionality between CTV and ANYPREVOUT, I think= it
> makes sense to decompose their operations into their constituent piece= s and
> reassemble their behaviour programmatically.=C2=A0 To this end, I'= d like to
> instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY.
>
> OP_TXHASH would pop a txhash flag from the stack and compute a (tagged= )
> txhash in accordance with that flag, and push the resulting hash onto = the
> stack.

It may be worth noting that OP_TXHASH can be further decomposed into
OP_TX (and OP_TAGGEDHASH, or just reuse OP_SHA256).

OP_TX would place the concatenated selected fields onto the stack
(rather than hashing them) This is more compact for some tests
(e.g. testing tx version for 2 is "OP_TX(version) 1 OP_EQUALS" vs=
"OP_TXHASH(version) 012345678...aabbccddeeff OP_EQUALS"), and als= o range
testing (e.g amount less than X or greater than X, or less than 3 inputs).<= br>
> I believe the difficulties with upgrading TXHASH can be mitigated by > designing a robust set of TXHASH flags from the start.=C2=A0 For examp= le having
> bits to control whether (1) the version is covered; (2) the locktime i= s
> covered; (3) txids are covered; (4) sequence numbers are covered; (5) = input
> amounts are covered; (6) input scriptpubkeys are covered; (7) number o= f
> inputs is covered; (8) output amounts are covered; (9) output scriptpu= bkeys
> are covered; (10) number of outputs is covered; (11) the tapbranch is<= br> > covered; (12) the tapleaf is covered; (13) the opseparator value is > covered; (14) whether all, one, or no inputs are covered; (15) whether= all,
> one or no outputs are covered; (16) whether the one input position is<= br> > covered; (17) whether the one output position is covered; (18) whether= the
> sighash flags are covered or not (note: whether or not the sighash fla= gs
> are or are not covered must itself be covered).=C2=A0 Possibly specify= ing which
> input or output position is covered in the single case and whether the=
> position is relative to the input's position or is an absolute pos= ition.

These easily map onto OP_TX, "(1) the version is pushed as u32, (2) th= e
locktime is pushed as u32, ...".

We might want to push SHA256() of scripts instead of scripts themselves, to reduce possibility of DoS.

I suggest, also, that 14 (and similarly 15) be defined two bits:
00 - no inputs
01 - all inputs
10 - current input
11 - pop number from stack, fail if >=3D number of inputs or no stack el= ems.

Cheers,
Rusty.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000005733ef05d77a3c84--