MIME-Version: 1.0
References: <CAHUJnBBFsS597ZRdAtwONMAz1r7gQbrXULzdNtEVxOPENx+tDg@mail.gmail.com>
 <CAGpPWDYvvtCJLsr1SqghugfntnmnKw+GOtufp07d8sN-5vKa0w@mail.gmail.com>
 <CAHUJnBAfnmfs2nY3HFRhzNL6ztpZT3dgqe5wCxuO3qpk0OsgRg@mail.gmail.com>
 <CAGpPWDabAbY3nS-1QATrzLj+O4dxfs4Fo0EuYFftNdjw_gwRPw@mail.gmail.com>
In-Reply-To: <CAGpPWDabAbY3nS-1QATrzLj+O4dxfs4Fo0EuYFftNdjw_gwRPw@mail.gmail.com>
From: Bram Cohen <bram@chia.net>
Date: Thu, 20 Jan 2022 11:23:30 -0800
Message-ID: <CAHUJnBAFV6qFDjYkO_ByfDOp1rwz4S1xQc9hSJj5Jpsb7DdVwQ@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a4efc305d608706d"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Covenants and capabilities in the UTXO model
Precedence: list

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

On Tue, Jan 18, 2022 at 6:25 PM Billy Tetrud <billy.tetrud@gmail.com> wrote:

> > '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.
>

Two concepts here. First of all Bitcoin doesn't have a strong single
concept of a 'parent', it just has transactions where all the parents lead
to all the children. For this sort of trickery to work more information
needs to be added to specify which of the inputs is the parent of each of
the outputs.

Second what in practice happens is that a coin can check what its own id
is, then verify the secure hash chain from its parent to itself so that it
knows what the parent looked like. For a Singleton it can then rely on the
fact that its ancestors enforced that they each only had one child to know
that it's the only descendant. In some sense this is like covenants which
point backwards in time although that information is already there in
principle because of the secure hash chain but hard to parse.


>
> >  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.
>

Don't full nodes by definition have to have the whole chain? This does make
pruned nodes difficult, but it could also have rules like you can only
point back so far.

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

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Jan 18, 2022 at 6:25 PM Billy Tet=
rud &lt;<a href=3D"mailto:billy.tetrud@gmail.com">billy.tetrud@gmail.com</a=
>&gt; wrote:<br></div><div class=3D"gmail_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"ltr"><div>&gt; &#39;assert that my pare=
nt has a scriptpubkey of X&#39;... That way you can, for example, have a UT=
XO which only allows itself to be absorbed by a transaction also involving =
a UTXO with a particular capability</div><div><br></div><div>I&#39;m not su=
re I fully follow. I usually think about covenants as having the reverse fo=
rm, 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 c=
an only be spent if the resulting outputs of that transaction all share the=
 same script? I see <a href=3D"https://chialisp.com/docs/puzzles/singletons=
/" target=3D"_blank">this page</a>=C2=A0but i don&#39;t understand how thos=
e concepts relate to covenants.</div></div></blockquote><div><br></div><div=
>Two concepts here. First of all Bitcoin doesn&#39;t have a strong single c=
oncept of a &#39;parent&#39;, it just has transactions where all the parent=
s lead to all the children. For this sort of trickery to work more informat=
ion needs to be added to specify which of the inputs is the parent of each =
of the outputs.</div><div><br></div><div>Second what in practice happens is=
 that a coin can check what its own id is, then verify the secure hash chai=
n from its parent to itself so that it knows what the parent looked like. F=
or a Singleton it can then rely on the fact that its ancestors enforced tha=
t they each only had one child to know that it&#39;s the only descendant. I=
n some sense this is like covenants which point backwards in time although =
that information is already there in principle because of the secure hash c=
hain but hard to parse.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><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></bloc=
kquote><div><br></div><div>Don&#39;t full nodes by definition have to have =
the whole chain? This does make pruned nodes difficult, but it could also h=
ave rules like you can only point back so far.</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div>
</blockquote></div></div>

--000000000000a4efc305d608706d--