path: root/f9/fb8b4b42ebab4bb486679dcd87540b2550c1cf

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 10846C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 18:57:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id F2DF782A0B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 18:57:49 +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 7Iu7oxrIHhLp
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 18:57:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [IPv6:2a00:1450:4864:20::230])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 9AA6B80BB7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 18:57:48 +0000 (UTC)
Received: by mail-lj1-x230.google.com with SMTP id o9so23272038ljq.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Feb 2022 10:57:48 -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=pAyXeYL3TRrQ9CIPCT0cdoBG/Gdctt/qhNX33wuMv1k=;
 b=VnSmG3+3jpc9Z9G7Y2cnmQeO4NKp/fFMeCAk3jq4IhfkbBQE2/qpME1ujdDXYxqid0
 eDqPmvXvNuuV5kAyjYG2+U5KNSpB2vEi6Xp/yJZjGPkqOBVrTtV1MhDkNyPdkSEg+q25
 p7LIxI2qUjk/bCQbyiI46YL/r9z1kIZSpKJ2sYKvQccQHF91ozyMgfuZK3cC0luoFn5Q
 Opu+O+q7Fu9m2bk747NtTqba1s8rCn8JuBvvKKgzPk6gEkO5b4brJ50SJmReGDpTKQqA
 GvxIF6h4PKgzkSZ/0T2aKa028y68OKXbROUqTIIrGwHF3HhHkDjUm56O4SF4jsVxw7o8
 PqQA==
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=pAyXeYL3TRrQ9CIPCT0cdoBG/Gdctt/qhNX33wuMv1k=;
 b=pYYDH5mA0C8f//nz+mtMGjTT9GybondvE3Ef5UrkFcKSSWzzRIgiTWf1cBjzLgfDOS
 vbJPMsP1CjgpKhiy7qrAbRfw1H5Yf1MM5TlQWqigRdBc8v9sugGMTIm1sNrnDyuMQi1R
 DgNh94ohlNTvKWgxZlIMv3/hh7SwDLOTkaCVWwYk+O5bA5sJAbmCssYs2KIHSpBPMJB2
 H+Dj2Hi5/RQ0I7XhLlmBqHqWcC+9nR1IlQsg5LQT/uR0/IAkGKXfnguf+Xs4UpfzWHd+
 aqmuChP3dic0j12vet8b3qsr0cauUoLkb94GFY5c1iDUASBPkV+qojIvUyAEZ6AVO21l
 kibg==
X-Gm-Message-State: AOAM532t4Vod4vGIyjO/9WP2jroMrxv3TK1RHCBoRnEmPQBfmityKR5B
 Thqy8pmT8FliiPhp28Yyxx5MUGR09v/noLc+wBk=
X-Google-Smtp-Source: ABdhPJzUoXxT+NXVPXvryGB1U6X/3b9mR2UWgm9WYRhGtob18JUI7og5g9ZnvRIcaOkcf34AzyLtdLMCBwmGVc2D38k=
X-Received: by 2002:a2e:9793:: with SMTP id y19mr270442lji.425.1644951466361; 
 Tue, 15 Feb 2022 10:57:46 -0800 (PST)
MIME-Version: 1.0
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
 <87leymuiu8.fsf@rustcorp.com.au>
 <CAD5xwhgP2_51Dvar0f1tsMrCXZ61W9-HnLgR45D-54Oc7-X1ag@mail.gmail.com>
 <87k0dwr015.fsf@rustcorp.com.au>
In-Reply-To: <87k0dwr015.fsf@rustcorp.com.au>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Tue, 15 Feb 2022 10:57:35 -0800
Message-ID: <CAD5xwhi4y1NiZ__c1WY-rCV3XBzN5yxY1Zox6Mc1FTjxUhXK9A@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: multipart/alternative; boundary="000000000000d3459805d8131b44"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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, 15 Feb 2022 18:57:50 -0000

--000000000000d3459805d8131b44
Content-Type: text/plain; charset="UTF-8"

Hi Rusty,

Please see my post in the other email thread
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html

The differences in this regard are several, and worth understanding beyond
"you can iterate CTV". I'd note a few clear examples for showing that "CTV
is just as powerful" is not a valid claim:

1) CTV requires the contract to be fully enumerated and is non-recursive.
For example, a simple contract that allows n participants to take an action
in any order requires factorially many pre-computations, not just linear or
constant. For reference, 24! is about 2**80. Whereas for a more
interpretive covenant -- which is often introduced with the features for
recursion -- you can compute the programs for these addresses in constant
time.
2) CTV requires the contract to be fully enumerated: For example, a simple
contract one could write is "Output 0 script matches Output 1", and the set
of outcomes is again unbounded a-priori. With CTV you need to know the set
of pairs you'd like to be able to expand to a-priori
3) Combining 1 and 2, you could imagine recursing on an open-ended thing
like creating many identical outputs over time but not constraining what
those outputs are. E.g., Output 0 matches Input 0, Output 1 matches Output
2.

I think for your point the inverse seems to hold: for the limited
situations we might want to set up, CTV often ends up being sufficient
because usually we can enumerate all the possible outcomes we'd like (or at
least find a mapping onto such a construction). CTV is indeed very
powerful, but as I demonstrated above, not powerful in the same way
("Complexity Class") that OP_TX or TXHASH might be.

At the very least we should clearly understand *what* and *why* we are
advocating for more sophisticated designs and have a thorough understanding
of the protocol complexity we are motivated to introduce the expanded
functionality. Further, if one advocates for TX/TXHASH on a featureful
basis, it's at least a technical ACK on the functionality CTV is
introducing (as it is a subset) and perhaps a disagreement on project
management, which I think is worth noting. There is a very wide gap between
"X is unsafe" and "I prefer Y which X is a subset of ''.

I'll close by repeating : Whether that [the recursive/open ended
properties] is an issue or not precluding this sort of design or not, I
defer to others.

Best,

Jeremy




Best,

Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>


On Tue, Feb 15, 2022 at 12:46 AM Rusty Russell <rusty@rustcorp.com.au>
wrote:

> Jeremy Rubin <jeremy.l.rubin@gmail.com> writes:
> > 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.
>
> Good point!
>
> But I think it's a distinction without meaning: AFAICT iterative
> covenants are possible with OP_CTV and just as powerful, though
> technically finite.  I can constrain the next 100M spends, for
> example: if I insist on those each having incrementing nLocktime,
> that's effectively forever.
>
> Thanks!
> Rusty.
>

--000000000000d3459805d8131b44
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"auto"><div dir=3D"ltr"><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000">Hi Rusty,</div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000">Please see my post in the other=C2=A0email thread=
=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
22-February/019886.html" rel=3D"noreferrer" target=3D"_blank">https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html</a></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00">The differences in this regard are several, and worth understanding bey=
ond &quot;you can iterate CTV&quot;. I&#39;d note a few clear examples for =
showing that &quot;CTV is just as powerful&quot; is not a valid claim:</div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
">1) CTV requires the contract to be fully enumerated and is non-recursive.=
 For example, a simple contract that allows n participants to take an actio=
n in any order requires factorially many pre-computations, not just linear =
or constant. For reference, 24! is about 2**80. Whereas for a more interpre=
tive covenant -- which is often introduced with the features for recursion =
-- you can compute the programs for these addresses in constant time.</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000">2) CTV requires the contract to be fully e=
numerated: For example, a simple contract one could write is &quot;Output 0=
 script matches Output 1&quot;, and the set of outcomes is again unbounded =
a-priori. With CTV you need to know the set of pairs you&#39;d like to be a=
ble to expand to a-priori</div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:#000000">3) Combinin=
g 1 and 2, you could imagine recursing on an open-ended thing like creating=
 many identical outputs over time but not constraining what those outputs a=
re. E.g., Output 0 matches Input 0, Output 1 matches Output 2.</div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000">I thin=
k for your point the inverse seems to hold: for the limited situations we m=
ight want to set up, CTV often ends up being sufficient because usually we =
can enumerate all the possible outcomes we&#39;d like (or at least find a m=
apping onto such a construction). CTV is indeed very powerful, but as I dem=
onstrated above, not powerful in the same way (&quot;Complexity Class&quot;=
) that OP_TX or TXHASH might be. </div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000">At the very least we should clear=
ly understand <i>what</i>=C2=A0and <i>why</i>=C2=A0we are advocating for mo=
re sophisticated designs and have a thorough understanding of the protocol =
complexity we are motivated to introduce the expanded functionality.=C2=A0F=
urther, if one advocates for TX/TXHASH on a featureful basis, it&#39;s at l=
east a technical ACK on the functionality CTV is introducing (as it is a su=
bset) and perhaps a disagreement on project management, which I think is wo=
rth noting. There is a very wide gap between &quot;X is unsafe&quot; and &q=
uot;I prefer Y which X is a subset of &#39;&#39;.<br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000"><div class=3D"g=
mail_default">I&#39;ll close by repeating : Whether that [the recursive/ope=
n ended properties] is an issue or not precluding this sort of design or no=
t, I defer to others.</div></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000">Best,</div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000">Jeremy</div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000">Best,</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Jeremy</div><div><div dir=
=3D"ltr" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=
=3D"https://twitter.com/JeremyRubin" rel=3D"noreferrer" target=3D"_blank">@=
JeremyRubin</a><br></div></div></div><br></div></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Feb 15, 2022=
 at 12:46 AM Rusty Russell &lt;<a href=3D"mailto:rusty@rustcorp.com.au" rel=
=3D"noreferrer" target=3D"_blank">rusty@rustcorp.com.au</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,2=
04);padding-left:1ex">Jeremy Rubin &lt;<a href=3D"mailto:jeremy.l.rubin@gma=
il.com" rel=3D"noreferrer" target=3D"_blank">jeremy.l.rubin@gmail.com</a>&g=
t; writes:<br>
&gt; Rusty,<br>
&gt;<br>
&gt; Note that this sort of design introduces recursive covenants similarly=
 to<br>
&gt; how I described above.<br>
&gt;<br>
&gt; Whether that is an issue or not precluding this sort of design or not,=
 I<br>
&gt; defer to others.<br>
<br>
Good point!<br>
<br>
But I think it&#39;s a distinction without meaning: AFAICT iterative<br>
covenants are possible with OP_CTV and just as powerful, though<br>
technically finite.=C2=A0 I can constrain the next 100M spends, for<br>
example: if I insist on those each having incrementing nLocktime,<br>
that&#39;s effectively forever.<br>
<br>
Thanks!<br>
Rusty.<br>
</blockquote></div>

--000000000000d3459805d8131b44--