path: root/31/67e54cabdf3d7401e4ef7cf042ce3c7dbac986

Return-Path: <bram@chia.net>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9EB31C002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 17:16:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 875FC812E7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 17:16:40 +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: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=chia.net
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 FLuyrEs5gYPt
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 17:16:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
 [IPv6:2a00:1450:4864:20::133])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 5EB53812A8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 17:16:39 +0000 (UTC)
Received: by mail-lf1-x133.google.com with SMTP id m1so73550825lfq.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 09:16:39 -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=sy9edOfxJY6n1wpl72P/AIRWUFXyjwbw9LHf8RPxzak=;
 b=axZ/5Gq4LoDA6o8JUfq2RyOc8S5uHdAW4g8Fb/W+E9aWowBp6ZshmFzCQHT64SeAXh
 Vrw3Voop/f70UteJFlOoZqlBOFjd02O/5XnNBFA7qIG9U+YURVMayi0jm/jt1ua7Nn1B
 AmNfkRQFKbCVJYV6A4XL2wiNxw6PHftg3J3hXx55d7I+H+QJdLFNyCppd0sNG7I44R0m
 rNBpwaItIlQh8Nohb08Uy4+NGdoR4g+hMZ1gUFFu6jrCYrTsFDVNi2pk/icNK8gsDzPu
 VFIboBdEHKWJWq6QqmuEcz5Gd1JnlOYtB0zQ/UMweiQpOViRd0g2tXsrkxkHf1VBW1LG
 6t7Q==
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=sy9edOfxJY6n1wpl72P/AIRWUFXyjwbw9LHf8RPxzak=;
 b=0XGPbX79Q5KxEiJSbmO1+PWhtRWGzJVzZcJLsHRMt/bUSuBXrzc+Knf5D8fstwhiKa
 slsXYOGybjZASN1BlRzoXzwUD35NWo0vXpsNwJvgrpVIqCETXxa4C3I7idxksEdGH2Aq
 llyhj1nq3wr8Frgao82cOKaduLm2hz67/UrK8cjFJXoQhrZ1oBi5PNvf8L5j7u4PtMLr
 VNJXnZJB30S0mp6KIn/Z8qSE9hmvpSgvrDviTSgVKnX4dnKaea3QjfFJc/aSyf4INXl0
 R/i9saoRp4eMTYM/QVVBbRKJ2oqkopR8zYQrXDk5fSz+27FHfVNs/I7416rbd2tO+aCQ
 DfeQ==
X-Gm-Message-State: AOAM531WhIibAcvG/DT6rdIE1LcINVSwJZuiNfG8kQMuearmT8mc8q8Z
 9802Mvr3E9MyGJ+G98a4QpcFv5RtFk2fmwstvdqdlA==
X-Google-Smtp-Source: ABdhPJzfLkfFsknyF//FEdUuc/BXGQjUelxY3m3Il8QgDlRg7MuKaJ0CPpGZD8vAWAyk+Ye/WsosprrleWHKWAdodJo=
X-Received: by 2002:a05:6512:31c6:: with SMTP id
 j6mr16149407lfe.471.1642526197051; 
 Tue, 18 Jan 2022 09:16:37 -0800 (PST)
MIME-Version: 1.0
References: <CAHUJnBBFsS597ZRdAtwONMAz1r7gQbrXULzdNtEVxOPENx+tDg@mail.gmail.com>
 <CAGpPWDYvvtCJLsr1SqghugfntnmnKw+GOtufp07d8sN-5vKa0w@mail.gmail.com>
In-Reply-To: <CAGpPWDYvvtCJLsr1SqghugfntnmnKw+GOtufp07d8sN-5vKa0w@mail.gmail.com>
From: Bram Cohen <bram@chia.net>
Date: Tue, 18 Jan 2022 09:16:25 -0800
Message-ID: <CAHUJnBAfnmfs2nY3HFRhzNL6ztpZT3dgqe5wCxuO3qpk0OsgRg@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000828ccb05d5de6e24"
X-Mailman-Approved-At: Tue, 18 Jan 2022 19:14:53 +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: Tue, 18 Jan 2022 17:16:40 -0000

--000000000000828ccb05d5de6e24
Content-Type: text/plain; charset="UTF-8"

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.

--000000000000828ccb05d5de6e24
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 7:10 AM 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">&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 class=3D"gmail-Apple-=
interchange-newline"><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div><br></div><div>&gt; Once you start imple=
menting complex general purpose functionality it tends to get very expensiv=
e very fast and is likely impractical unless 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 sc=
ripts in some way, it could save a lot of bandwidth which would help bitcoi=
n scale better. One thing we could do is have a specific set of pre-ordaine=
d script snippets that are given a shorthand that&#39;s stored in the softw=
are and explicitly shouldn&#39;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&#39;t be cha=
nged by this approach.=C2=A0</div></div></blockquote><div><br></div><div>On=
e approach is to allow references to old blocks so code snippets can be pul=
led out of them. That avoids having to define the &#39;common sections&#39;=
 up front. Charging for virtual vbytes unfortunately keeps smart functional=
ity very expensive and the point is to make it not so expensive.</div><div>=
=C2=A0</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"l=
tr"><div>&gt; For a payment to someone to come with a rider where they coul=
d accept it and think their system was working properly for a while until y=
ou exercised some kind of retroactive veto on new action or even clawback w=
ould obviously be unacceptable behavior.<br></div><div><br></div><div>I def=
initely agree. A payment&#39;s covenant should be completely knowable to th=
e recipient, and recipients shouldn&#39;t accept random covenants they have=
n&#39;t explicitly accepted on their own.=C2=A0</div><div><br></div><div>&g=
t; for payments to come with covenants but the recipient not even be able t=
o parse them unless they&#39;re fully buying into that behavior is much mor=
e reasonable.=C2=A0</div><div><br></div><div>The recipient not being able t=
o parse them? Couldn&#39;t that result in exactly the situation above you s=
aid was not acceptable? The recipient must be able to know all the possibil=
ities of the covenant or there might be some secret retroactive clawback in=
 there waiting to bite them.</div></div></blockquote><div><br></div><div>No=
t sure what you&#39;re saying. If the recipient can&#39;t parse a UTXO the =
defined behavior should be that they assume it&#39;s bricked.</div></div></=
div>

--000000000000828ccb05d5de6e24--