path: root/7d/d0d718b874e8f1c375f5dd744197e0d8fc780a

Return-Path: <bram@chia.net>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EE93DC002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jan 2022 19:23:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id CC7264016B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jan 2022 19:23:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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=chia.net
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 PeCiTgiMO84Z
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jan 2022 19:23:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
 [IPv6:2a00:1450:4864:20::12e])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 8CE3740108
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jan 2022 19:23:43 +0000 (UTC)
Received: by mail-lf1-x12e.google.com with SMTP id o12so25400258lfu.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Jan 2022 11:23:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=floRBZeo5j90qDH2i8OaNIVi4MK+luF5BfMkp3ahyH0=;
 b=MEAHEYeiYZOW4HkMm8CLc+zhw54vat3kp0lGF/9U6JwUwItV8tYjiLADONnioi86c8
 dPFFP1rQ5OkidzWGOQiwnSbznTs5R7JGOjzrySkI+Fs2uzJ9hAf2YkJJ/njpqYHYtEjN
 3Vhk7vYkmXDP7vNlCQuJf36177DOgQUjVvdqJRygs5UaArlVR4DdvykPRdSS35ZgvVs1
 ua28cwgJuCpRkgMFWHemFHuOdWs8pvTrQOYHaQLZqz68F146/6DuiJS2FnbB+lKTHK7W
 J2ZSv77qPWuWVtom4yynTAK1dyMAvmOioxHfpFZJo2WpcVynw/A8hlCTlp/cUox4Douh
 86AQ==
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=floRBZeo5j90qDH2i8OaNIVi4MK+luF5BfMkp3ahyH0=;
 b=w6e8huy2gHxSAkQL/jww8H/Yrygciv76DIUwOKSP+8fPn+CwHy5YUPh/7S+FvALSAn
 n2eGi1AZqzN9RH0Uxxb1Pl3wC11d5guYPAtKBPifVSTbedEsJh9PuMUymB8I56UgwbGL
 AQcMtEj/RMGykFuZ06XvW42ZOcie59rhNwoeX8h7Wl1iJyudUPIZ+q50y0B/iTWleoei
 FZ3JIBlnXC7dqVhKJzrRjFq3zpKYVsp/Zf6Ian/d9uHvkub4JN7vrrXHT8ROAKqjPvB7
 UMvmWsIXGPRM05R9x/xvIpxM/PF7idssTISM1UGpsaMpmkjHqgtwROdu8KMuPzkhhYdT
 lBxQ==
X-Gm-Message-State: AOAM533HZiZYYVQRNJ4FiyGFq+nehcYwY2uARYiliv40oi3cwFin21II
 KLoQmkxz30dpVBrCTlNpCGfpaB4wC+yI348JKQpeeQ==
X-Google-Smtp-Source: ABdhPJzj2RRQEL/lqG1FZBmWPcR5OePgveb3qYV4SPlqcQFK4XyWsITfEHtteVknHTwsRW4Q5Sc+Q2RcBmfwC/Puvpw=
X-Received: by 2002:a05:6512:16a6:: with SMTP id
 bu38mr533423lfb.454.1642706621484; 
 Thu, 20 Jan 2022 11:23:41 -0800 (PST)
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"
X-Mailman-Approved-At: Thu, 20 Jan 2022 19:31:04 +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: Thu, 20 Jan 2022 19:23:47 -0000

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