Return-Path: <jeremy.l.rubin@gmail.com> Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1CAC0C000B for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; Tue, 8 Feb 2022 04:34:44 +0000 (UTC) Received: by mail-lf1-x12f.google.com with SMTP id f10so30904428lfu.8 for <bitcoin-dev@lists.linuxfoundation.org>; 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: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com> <87leymuiu8.fsf@rustcorp.com.au> In-Reply-To: <87leymuiu8.fsf@rustcorp.com.au> From: Jeremy Rubin <jeremy.l.rubin@gmail.com> Date: Mon, 7 Feb 2022 20:34:30 -0800 Message-ID: <CAD5xwhgP2_51Dvar0f1tsMrCXZ61W9-HnLgR45D-54Oc7-X1ag@mail.gmail.com> To: Rusty Russell <rusty@rustcorp.com.au>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 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 <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, 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 <bitcoin-dev@lists.linuxfoundation.org> > 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 <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= lvetica,sans-serif;font-size:small;color:#000000"></div><div><div dir=3D"lt= r" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D= "ltr"><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san= s-serif;font-size:small;color:rgb(0,0,0)">Rusty,</div><div class=3D"gmail_d= efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col= or:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:= arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Note that this= sort of design introduces recursive covenants similarly to how I described= above.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet= ica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gm= ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal= l;color:rgb(0,0,0)">Whether that is an issue or not precluding this sort of= design or not, I defer to others.</div><br></div><div dir=3D"ltr"><div cla= ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s= ize:small;color:rgb(0,0,0)">Best,</div><div class=3D"gmail_default" style= =3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)= "><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti= ca,sans-serif;font-size:small;color:rgb(0,0,0)">Jeremy</div><br></div></div= ></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Mon, Feb 7, 2022 at 7:57 PM Rusty Russell via bitcoin-dev <<a = href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.lin= uxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s= olid;border-left-color:rgb(204,204,204);padding-left:1ex">Russell O'Con= nor via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation= .org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> write= s:<br> > Given the overlap in functionality between CTV and ANYPREVOUT, I think= it<br> > makes sense to decompose their operations into their constituent piece= s and<br> > reassemble their behaviour programmatically.=C2=A0 To this end, I'= d like to<br> > instead propose OP_TXHASH and OP_CHECKSIGFROMSTACKVERIFY.<br> ><br> > OP_TXHASH would pop a txhash flag from the stack and compute a (tagged= )<br> > txhash in accordance with that flag, and push the resulting hash onto = the<br> > stack.<br> <br> It may be worth noting that OP_TXHASH can be further decomposed into<br> OP_TX (and OP_TAGGEDHASH, or just reuse OP_SHA256).<br> <br> OP_TX would place the concatenated selected fields onto the stack<br> (rather than hashing them) This is more compact for some tests<br> (e.g. testing tx version for 2 is "OP_TX(version) 1 OP_EQUALS" vs= <br> "OP_TXHASH(version) 012345678...aabbccddeeff OP_EQUALS"), and als= o range<br> testing (e.g amount less than X or greater than X, or less than 3 inputs).<= br> <br> > I believe the difficulties with upgrading TXHASH can be mitigated by<b= r> > designing a robust set of TXHASH flags from the start.=C2=A0 For examp= le having<br> > bits to control whether (1) the version is covered; (2) the locktime i= s<br> > covered; (3) txids are covered; (4) sequence numbers are covered; (5) = input<br> > amounts are covered; (6) input scriptpubkeys are covered; (7) number o= f<br> > inputs is covered; (8) output amounts are covered; (9) output scriptpu= bkeys<br> > are covered; (10) number of outputs is covered; (11) the tapbranch is<= br> > covered; (12) the tapleaf is covered; (13) the opseparator value is<br= > > covered; (14) whether all, one, or no inputs are covered; (15) whether= all,<br> > 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<br> > sighash flags are covered or not (note: whether or not the sighash fla= gs<br> > are or are not covered must itself be covered).=C2=A0 Possibly specify= ing which<br> > input or output position is covered in the single case and whether the= <br> > position is relative to the input's position or is an absolute pos= ition.<br> <br> These easily map onto OP_TX, "(1) the version is pushed as u32, (2) th= e<br> locktime is pushed as u32, ...".<br> <br> We might want to push SHA256() of scripts instead of scripts themselves,<br= > to reduce possibility of DoS.<br> <br> I suggest, also, that 14 (and similarly 15) be defined two bits:<br> 00 - no inputs<br> 01 - all inputs<br> 10 - current input<br> 11 - pop number from stack, fail if >=3D number of inputs or no stack el= ems.<br> <br> Cheers,<br> Rusty.<br> _______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> </blockquote></div> --0000000000005733ef05d77a3c84--