path: root/e1/4ccc2f9a6693dbc478962ac83239a9af794dd0

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 521AAC002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Jan 2022 02:25:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 392A540180
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Jan 2022 02:25:07 +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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id qKQ2PXerxSCK
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Jan 2022 02:25:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
 [IPv6:2a00:1450:4864:20::532])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 6F80D40159
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Jan 2022 02:25:05 +0000 (UTC)
Received: by mail-ed1-x532.google.com with SMTP id c71so4089514edf.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 18:25:05 -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=WrX23HsOCosOSc0UDoiNpRamHJDpiOeJ2ZFg/sfgBaw=;
 b=XAqW03O9fwgpJycMw1k9o2+Ki4UjMCagJrXrxklW7tTCCcSpCpYwQOPFQi4p27xb8z
 TND43IoAVW7FfVb+8vQmBep66XV4Zsa93IzyT7JnkdTX/LHsl4oM48FGI37gwMa7Iaw4
 liCeHzICvTXccT9H0xA1ZG1WBD3pK1w1Sa1VeqyolhhAjozU0BE++9WfsaThD78yGsTJ
 4cpOgqR6yut3DVGf0KrPEtLFv8MSrIUrN75Gm05OnTPANrC7wY0IyEfgL7rnVaGW84ME
 +WFXV0wqwS6/NEjaL7mdDQM92LnH3hr0yrMo9k6QO9hUUccCu+lS5Wvej1MmqMqr3qSr
 RrUA==
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=WrX23HsOCosOSc0UDoiNpRamHJDpiOeJ2ZFg/sfgBaw=;
 b=niKRUavDSENBScz+wKaYHZD+lbnohXrkaq+xFOI9he8c7rYmQEGrQsAwivRSLdutEj
 YAac0F/88Qmh9+5p/PJQhArm+2Qk7Lsvg/c+Mmn0Xk37MSLjyj66wYEjfNgChU/sBCv+
 scGZ7k/YGfIsXqOyamlHhCfYfSiVe/P3sFJzrBFGnSwPq7yb3dOgN9WYPnFS+nSjOG/5
 6lFO0odPbqR0k5xJqmPVVyzu4hk2E60jPY8c2+139v2dfB+dqrT34yuF8eOM8Mu2L27k
 9qeV4m6qviukZrKX5rIchOhlQFjf6CTPMuZByu9s6wYf5Uxjj4Zm8oIq5a3UpxOs21gm
 p/HA==
X-Gm-Message-State: AOAM530lwcu2AUSolrj5gvvrsyvUo7LoBLgDr7bwfXLbUheFxTjK65Yz
 9zgQWbTtJbePrdGIMBXs4oLgitGFYtz7lyOLAAmZWqIslIo=
X-Google-Smtp-Source: ABdhPJzYX4rALQI68MlLswdYazngtXX2iY+9jwpJtfbwsNDbT9HjgkhGvF6/bIR71aXwqfCrUeNv+sUC1dVUKxEbYto=
X-Received: by 2002:a05:6402:350b:: with SMTP id
 b11mr28363136edd.355.1642559103564; 
 Tue, 18 Jan 2022 18:25:03 -0800 (PST)
MIME-Version: 1.0
References: <CAHUJnBBFsS597ZRdAtwONMAz1r7gQbrXULzdNtEVxOPENx+tDg@mail.gmail.com>
 <CAGpPWDYvvtCJLsr1SqghugfntnmnKw+GOtufp07d8sN-5vKa0w@mail.gmail.com>
 <CAHUJnBAfnmfs2nY3HFRhzNL6ztpZT3dgqe5wCxuO3qpk0OsgRg@mail.gmail.com>
In-Reply-To: <CAHUJnBAfnmfs2nY3HFRhzNL6ztpZT3dgqe5wCxuO3qpk0OsgRg@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 18 Jan 2022 20:24:47 -0600
Message-ID: <CAGpPWDabAbY3nS-1QATrzLj+O4dxfs4Fo0EuYFftNdjw_gwRPw@mail.gmail.com>
To: Bram Cohen <bram@chia.net>
Content-Type: multipart/alternative; boundary="000000000000e400fc05d5e617a3"
X-Mailman-Approved-At: Wed, 19 Jan 2022 09:11:26 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Covenants and capabilities in the UTXO model
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: Wed, 19 Jan 2022 02:25:07 -0000

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

> 'assert that my parent has a scriptpubkey of X'... That way you can, for
example, have a UTXO which only allows itself to be absorbed by a
transaction also involving a UTXO with a particular capability

I'm not sure I fully follow. I usually think about covenants as having the
reverse form, that a parent would assert "my children must have a script of
the form XYZ". Are you saying you want to be able to specify that a UTXO
can only be spent if the resulting outputs of that transaction all share
the same script? I see this page
<https://chialisp.com/docs/puzzles/singletons/> but i don't understand how
those concepts relate to covenants.

>  allow references to old blocks so code snippets can be pulled out of them

Nodes currently aren't required to keep around the whole blockchain, but
your proposal sounds like it would require them to. I think this could be
pretty detrimental to future scalability. Monero, for example, has a
situation where its UTXO set is the whole blockchain because you can't
generally know what has been spent and what hasn't been. Allowing
references to old blocks would pull in all this old block data into the
UTXO set. So unless you're very careful about how or when you can reference
old blocks, this could cause issues.

> If the recipient can't parse a UTXO the defined behavior should be that
they assume it's bricked.

I must have misunderstood you. I think that's the appropriate response: if
you don't know everything about how a UTXO sent "to you" can be spent, you
can't really treat it as yours.


On Tue, Jan 18, 2022 at 11:16 AM Bram Cohen <bram@chia.net> wrote:

> On Tue, Jan 18, 2022 at 7:10 AM Billy Tetrud <billy.tetrud@gmail.com>
> wrote:
>
>> >  Since scriptpubkeys/scriptsigs continue to run ephemerally at
>> validation time full turing completeness is much less dangerous than people
>> fear.
>>
>> The covenant proposals I've seen that might give bitcoin turing
>> completeness require a turing complete process to be stepped such that each
>> step is a transaction paid for with a usual fee. This fact I think makes
>> the turing completeness a lot less scary. No single transaction would be
>> turing complete, while a sequence of them could be. But importantly, each
>> transaction has a strictly limited runtime and every script could continue
>> to have a calculable number of maximum runtime steps.
>>
>
> This flows naturally out of the UTXO model. In ETH you don't know how much
> transactions will cost in advance because things don't declare their state
> up front, but with all dependencies declared up front execution can be made
> completely deterministic.
>
>  > It would also probably be a good idea to add in a bunch of special
> purpose opcodes for making coherent statements about transactions since in
> Bitcoin they're a very complex and hard to parse format.
>
>>
>> What are some examples you're thinking of?
>>
>
> What's needed from a programming perspective is the ability to say 'assert
> that my parent has a scriptpubkey of X'. That way you can, for example,
> have a UTXO which only allows itself to be absorbed by a transaction also
> involving a UTXO with a particular capability ('pay to singleton' is a term
> for this) and that capability can be enforced by the scriptpubkey asserting
> that either its parent is the originator of it or that its parent also has
> the same type of scriptpubkey. This allows capabilities to be added without
> gunking up on chain state with things other than UTXOs.
>
>
>
>>
>> > Once you start implementing complex general purpose functionality it
>> tends to get very expensive very fast and is likely impractical unless
>> there's a way to compress or at least de-duplicate snippets of code which
>> are repeated on chain.
>>
>> I like this idea. If there was a way to dedupe scripts in some way, it
>> could save a lot of bandwidth which would help bitcoin scale better. One
>> thing we could do is have a specific set of pre-ordained script snippets
>> that are given a shorthand that's stored in the software and explicitly
>> shouldn't be transmitted long-hand. That would help for very standard
>> widespread things. We could even add in a consensus rule where short-handed
>> scripts pay for their expanded vbytes, not the vbytes of the compressed
>> version. This would mean the incentives wouldn't be changed by this
>> approach.
>>
>
> One approach is to allow references to old blocks so code snippets can be
> pulled out of them. That avoids having to define the 'common sections' up
> front. Charging for virtual vbytes unfortunately keeps smart functionality
> very expensive and the point is to make it not so expensive.
>
>
>> > For a payment to someone to come with a rider where they could accept
>> it and think their system was working properly for a while until you
>> exercised some kind of retroactive veto on new action or even clawback
>> would obviously be unacceptable behavior.
>>
>> I definitely agree. A payment's covenant should be completely knowable to
>> the recipient, and recipients shouldn't accept random covenants they
>> haven't explicitly accepted on their own.
>>
>> > for payments to come with covenants but the recipient not even be able
>> to parse them unless they're fully buying into that behavior is much more
>> reasonable.
>>
>> The recipient not being able to parse them? Couldn't that result in
>> exactly the situation above you said was not acceptable? The recipient must
>> be able to know all the possibilities of the covenant or there might be
>> some secret retroactive clawback in there waiting to bite them.
>>
>
> Not sure what you're saying. If the recipient can't parse a UTXO the
> defined behavior should be that they assume it's bricked.
>

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

<div dir=3D"ltr"><div>&gt; &#39;assert that my parent has a scriptpubkey of=
 X&#39;... That way you can, for example, have a UTXO which only allows its=
elf to be absorbed by a transaction also involving a UTXO with a particular=
 capability</div><div><br></div><div>I&#39;m not sure I fully follow. I usu=
ally think about covenants as having the reverse form, that a parent would =
assert &quot;my children must have a script of the form XYZ&quot;. Are you =
saying you want to be able to specify that a UTXO can only be spent if the =
resulting outputs of that transaction all share the same script? I see <a h=
ref=3D"https://chialisp.com/docs/puzzles/singletons/">this page</a>=C2=A0bu=
t i don&#39;t understand how those concepts relate to covenants.</div><div>=
<br></div>&gt;=C2=A0

allow references to old blocks so code snippets can be pulled out of them<d=
iv><br></div><div>Nodes currently aren&#39;t required to keep around the wh=
ole blockchain, but your proposal sounds like it would require them to. I t=
hink this could be pretty detrimental=C2=A0to future scalability. Monero, f=
or example, has a situation where its UTXO set is the whole blockchain beca=
use you can&#39;t generally know what has been spent and what hasn&#39;t be=
en. Allowing references to old blocks would pull in all this old block data=
 into the UTXO set. So unless you&#39;re very careful about how or when you=
 can reference old blocks, this could cause issues.=C2=A0</div><div><br></d=
iv><div>&gt; If the recipient can&#39;t parse a UTXO the defined behavior s=
hould be that they assume it&#39;s bricked.</div><div><br></div><div>I must=
 have misunderstood you. I think that&#39;s the appropriate response: if yo=
u don&#39;t know everything about how a UTXO sent &quot;to you&quot; can be=
 spent, you can&#39;t really treat it as yours.=C2=A0</div><div><br></div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Tue, Jan 18, 2022 at 11:16 AM Bram Cohen &lt;<a href=3D"mailto:bram@chia.=
net">bram@chia.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">On Tue, Jan 18, 2022 at=
 7:10 AM Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com" target=
=3D"_blank">billy.tetrud@gmail.com</a>&gt; wrote:<br></div><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r">&gt;=C2=A0

Since scriptpubkeys/scriptsigs=C2=A0continue to run ephemerally at validati=
on time full turing completeness is much less dangerous than people fear.=
=C2=A0<div><br></div><div>The covenant proposals I&#39;ve seen that might g=
ive bitcoin turing completeness require a turing complete process to be ste=
pped such that each step is a transaction paid for with a usual fee. This f=
act I think makes the turing completeness a lot less scary. No single trans=
action would be turing complete, while a sequence of them could be. But imp=
ortantly, each transaction has a strictly limited runtime and every script =
could continue to have a calculable number of maximum runtime steps.</div><=
/div></blockquote><div><br></div><div>This flows naturally out of the UTXO =
model. In ETH you don&#39;t know how much transactions will cost in advance=
 because things don&#39;t declare their state up front, but with all depend=
encies declared up front execution can be made completely deterministic.</d=
iv><div><br></div><div>=C2=A0&gt; It would also probably be a good idea to =
add in a bunch of special purpose opcodes for making coherent statements ab=
out transactions since in Bitcoin they&#39;re a very complex and hard to pa=
rse format.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div><br></div><div>What are some examples you&#39;re thinking of?=
</div></div></blockquote><div><br></div><div>What&#39;s needed from a progr=
amming perspective is the ability to say &#39;assert that my parent has a s=
criptpubkey of X&#39;. That way you can, for example, have a UTXO which onl=
y allows itself to be absorbed by a transaction also involving a UTXO with =
a particular capability (&#39;pay to singleton&#39; is a term for this) and=
 that capability can be enforced by the scriptpubkey asserting that either =
its parent is the originator of it or that its parent also has the same typ=
e of scriptpubkey. This allows capabilities to be added without gunking up =
on chain state with things other than UTXOs.</div><br><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br></d=
iv><div>&gt; Once you start implementing complex general purpose functional=
ity it tends to get very expensive very fast and is likely impractical unle=
ss there&#39;s a way to compress or at least de-duplicate=C2=A0snippets of =
code which are repeated on chain.</div><div><br></div><div>I like this idea=
. If there was a way to dedupe scripts in some way, it could save a lot of =
bandwidth which would help bitcoin scale better. One thing we could do is h=
ave a specific set of pre-ordained script snippets that are given a shortha=
nd that&#39;s stored in the software and explicitly shouldn&#39;t be transm=
itted long-hand. That would help for very standard widespread things. We co=
uld even add in a consensus rule where short-handed scripts pay for their e=
xpanded vbytes, not the vbytes of the compressed version. This would mean t=
he incentives wouldn&#39;t be changed by this approach.=C2=A0</div></div></=
blockquote><div><br></div><div>One approach is to allow references to old b=
locks so code snippets can be pulled out of them. That avoids having to def=
ine the &#39;common sections&#39; up front. Charging for virtual vbytes unf=
ortunately keeps smart functionality very expensive and the point is to mak=
e it not so expensive.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div>&gt; For a payment to someone to =
come with a rider where they could accept it and think their system was wor=
king properly for a while until you exercised some kind of retroactive veto=
 on new action or even clawback would obviously be unacceptable behavior.<b=
r></div><div><br></div><div>I definitely agree. A payment&#39;s covenant sh=
ould be completely knowable to the recipient, and recipients shouldn&#39;t =
accept random covenants they haven&#39;t explicitly accepted on their own.=
=C2=A0</div><div><br></div><div>&gt; for payments to come with covenants bu=
t the recipient not even be able to parse them unless they&#39;re fully buy=
ing into that behavior is much more reasonable.=C2=A0</div><div><br></div><=
div>The recipient not being able to parse them? Couldn&#39;t that result in=
 exactly the situation above you said was not acceptable? The recipient mus=
t be able to know all the possibilities of the covenant or there might be s=
ome secret retroactive clawback in there waiting to bite them.</div></div><=
/blockquote><div><br></div><div>Not sure what you&#39;re saying. If the rec=
ipient can&#39;t parse a UTXO the defined behavior should be that they assu=
me it&#39;s bricked.</div></div></div>
</blockquote></div>

--000000000000e400fc05d5e617a3--