path: root/89/3b75d527255fd3986387c51c9532a7ed11278f

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9E8FDC002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 15:10:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 9455B81D70
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 15:10:56 +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 Q_bChRf6YM1h
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 15:10:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [IPv6:2a00:1450:4864:20::534])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 3C50181D67
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 15:10:54 +0000 (UTC)
Received: by mail-ed1-x534.google.com with SMTP id q25so80909194edb.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Jan 2022 07:10:54 -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;
 bh=y6gUYvTCArsAqSSko0cMWrCnhuDXCoi/y/kHe2pToX8=;
 b=SnNZ8AGiL2MML0tj8os67Fo6zaZMOM4PznbkEw5x3sl5aUMAO2qZcph5X1/dgc7r6h
 phOYUwVNh7fCbIbQnd0xN3rb/KIoyNl/3O+Ee68l5mQTvz7A9GCjWQnxBBOpcYxHpIa4
 Gaub2cMU1mjJCOqZl9SF/JL0e/GaRnXjKnRi/XUC0i0UTjPmtuMsOH8uK1z39DZOzae4
 /CCvOUW9J64tUOO/rBRdPXbYnD9kYDGIr6gyJylcJBioCe4HfGPZ7abo4qoJ2lyHgkQv
 +OsArj7zpkO1djAnILpgOzSg+cY92l3gzu+HFfsMq+qrYHJtDGTl7/5Ot2GaOI7zXjE9
 PFqw==
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;
 bh=y6gUYvTCArsAqSSko0cMWrCnhuDXCoi/y/kHe2pToX8=;
 b=2jxcUBRmOsYXhEB9NQN5iBMf/E6N2xcNhHZGqx2b0S8K7NUO/f3NYrjrqXIBu5CWjN
 w2cAfTEeNtJyZEfzW747oPbO2sRprOglKKNaEjRB4GVB+ObpK/5wyovMGLYM+4+h67bJ
 byIdtdlh2wvERq198oeQY0xnBdLsYyyCJAqlrSV0rnCCaLP+3K6DgAQ+PBfl+12HcAYn
 67Etim65r6Vi5kP9QDmN26ddHymGixO/91sR+zA5NVntGMz3FHf9hogxdehhfU9WIL+K
 /yCguTOK+sETMlPowFXkMmIHqNo7ksB5NJmiH2/NuzSlHmpD7WNED+nJqQK7eF0LrUVG
 vpyA==
X-Gm-Message-State: AOAM533j3ZX0zOGKUvkndmr26o5zZjRgoCVYfVNCklOXz7m8glZ+7PY0
 +W/wSjt5910N+/ZV28nXLQNJK0vEk34LvbygAySapSVricU=
X-Google-Smtp-Source: ABdhPJwFn/waYtUjQ5OaXU302k/gUC+DCF8EN0PE9HNSHKFI7FZT2gsGtTBQlJydbSmWkcRydL8mxeVKIxaJBmj1fzo=
X-Received: by 2002:aa7:cd69:: with SMTP id ca9mr23816018edb.16.1642518652301; 
 Tue, 18 Jan 2022 07:10:52 -0800 (PST)
MIME-Version: 1.0
References: <CAHUJnBBFsS597ZRdAtwONMAz1r7gQbrXULzdNtEVxOPENx+tDg@mail.gmail.com>
In-Reply-To: <CAHUJnBBFsS597ZRdAtwONMAz1r7gQbrXULzdNtEVxOPENx+tDg@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 18 Jan 2022 09:10:33 -0600
Message-ID: <CAGpPWDYvvtCJLsr1SqghugfntnmnKw+GOtufp07d8sN-5vKa0w@mail.gmail.com>
To: Bram Cohen <bram@chia.net>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ceb29105d5dcac8d"
X-Mailman-Approved-At: Tue, 18 Jan 2022 16:25:13 +0000
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 15:10:56 -0000

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

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

> The main thing missing from what's expressed in transactions themselves
is a coherent notion of a single parent of each output instead of the
all-inputs-lead-to-all-outputs approach of transactions currently.

I'm curious to hear more about specifically what you mean by this. I think
there are covenant proposals that do that. TLUV has the concept of
specifying which output should have a script that's "modified" in a
particular way. CTV basically specifies a specific output set. My own
OP_CONSTRAINDESTINATION
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>
also specifies what outputs the value of the input is transferred to. Is
this what you mean?

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

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

We could also imagine a more dynamic approach, where nodes keep an index of
scripts or script snippets in some way, and keep around ones that it sees
most often. I'm not sure how this would work, since a script can contain a
lot of unique values and there's no clear way to split a script into
pieces. Perhaps script segments could be committed to the chain and nodes
could attempt to only store and reuse these paid-for segments, maybe only
the X most paid-for scripts (the scripts committed with the largest fee,
potentially across multiple explicit standalone commitments). However, this
dynamic approach would also have some scalability benefits, tho it would be
a bit more chaotic. Any node transmitting transactions would only need to
send the script segments when the node they're transmitting to requests
them. However, the extra script references also take up space, and so if
the ratio of how often the node has a script segment to how often they
don't is bad enough, this could a net negative scalability wise.

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



On Fri, Dec 31, 2021 at 6:41 PM Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There are a few different approaches to adding covenants and capabilities
> to the UTXO model with varying tradeoffs. It turns out that it can be done
> while making very few but not quite zero compromises to practices Bitcoin
> has been following so far.
>
> First, the good news: Full support for both capabilities and covenants can
> be added without changing the UTXO model whatsoever by adding some more
> programmatic capabilities to the language and doing some programmatic
> tricks. Since scriptpubkeys/scriptsigs continue to run ephemerally at
> validation time full turing completeness is much less dangerous than people
> fear. The main thing missing from what's expressed in transactions
> themselves is a coherent notion of a single parent of each output instead
> of the all-inputs-lead-to-all-outputs approach of transactions currently.
> 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.
>
> Now for the controversial stuff. 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. Currently
> Bitcoin has a strong policy that deciding which transactions to let into a
> block for maximum fee is a strictly linear optimization problem and while
> it's possible to keep things mostly that way making it completely strict is
> unlikely to workable. About as close as you can get is to make it so that
> each block can reference code snippets in previous blocks for
> deduplication, so at least the optimization is linear for each block by
> itself.
>
> Having covenants and capabilities at all is controversial in and of
> itself. With covenants the main issue is whether they're opt-in or opt-out.
> 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. But 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 main issue which people have raised with capabilities is that if you
> were to have colored coins whose value was substantially greater than the
> chain they were tokenized on then that could potentially create a business
> model for attacking the underlying chain. While this is a real concern
> tokenized assets have been out for a while now and have never come close to
> causing this to happen, so maybe people aren't so worried about it now.
>
> Given all the above caveats it turns out one weird trick is all you need
> to support general purpose capabilities: for a UTXO to have a capability
> its scriptpubkey asserts that its parent must either be the originator of
> that capability or also conform to the same parent-asserting format. More
> complex functionality such as supporting on-chain verifiable colored coins
> can also be done but it follows the same pattern: Capabilities are
> implemented as backwards pointing covenants.
>
> If you'd like to see a fleshed out implementation of these ideas (albeit
> in a slightly different model) there's quite a bit of stuff on
> chialisp.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<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><br></div><div>&gt; The main thing missing from what&#39;s expressed in=
 transactions themselves is a coherent notion of a single parent of each ou=
tput instead of the all-inputs-lead-to-all-outputs approach of transactions=
 currently.</div><div><br></div><div>I&#39;m curious to hear more about spe=
cifically what you mean by this. I think there are covenant proposals that =
do that. TLUV has the concept=C2=A0of specifying which output should have a=
 script that&#39;s &quot;modified&quot; in a particular way. CTV basically =
specifies a specific output set. My own <a href=3D"https://github.com/fresh=
eneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.m=
d">OP_CONSTRAINDESTINATION</a> also specifies what outputs the value of the=
 input is transferred to. Is this what you mean?</div><div><br></div><div>&=
gt; It would also probably be a good idea to add in a bunch of special purp=
ose opcodes for making coherent statements about transactions since in Bitc=
oin they&#39;re a very complex and hard to parse format.</div><div><br></di=
v><div>What are some examples you&#39;re thinking of?</div><div><br></div><=
div>&gt; Once you start implementing complex general purpose functionality =
it tends to get very expensive very fast and is likely impractical unless t=
here&#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 band=
width 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 t=
hat&#39;s stored in the software and explicitly shouldn&#39;t be transmitte=
d 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 expan=
ded vbytes, not the vbytes of the compressed version. This would mean the i=
ncentives wouldn&#39;t be changed by this approach.=C2=A0</div><div><br></d=
iv><div>We could also imagine a more dynamic approach, where nodes keep an =
index of scripts or script snippets in some way, and keep around ones that =
it sees most often. I&#39;m not sure how this would work, since a script ca=
n contain a lot of unique values and there&#39;s no clear way to split a sc=
ript into pieces. Perhaps script segments could be committed to the chain a=
nd nodes could attempt to only store and reuse these paid-for segments, may=
be only the X most paid-for=C2=A0scripts (the scripts committed with the la=
rgest fee, potentially across multiple explicit standalone commitments). Ho=
wever, this dynamic approach would also have some scalability benefits, tho=
 it would be a bit more chaotic. Any node transmitting transactions would o=
nly need to send the script segments when the node they&#39;re transmitting=
 to requests them. However, the extra script references also take up space,=
 and so if the ratio of how often the node has a script segment to how ofte=
n they don&#39;t is bad enough, this could a net negative scalability wise.=
=C2=A0</div><div><br></div><div>&gt; For a payment to someone to come with =
a rider where they could accept it and think their system was working prope=
rly for a while until you exercised some kind of retroactive veto on new ac=
tion or even clawback would obviously be unacceptable behavior.</div><div><=
br></div><div>I definitely agree. A payment&#39;s covenant should be comple=
tely knowable to the recipient, and recipients shouldn&#39;t accept random =
covenants they haven&#39;t explicitly accepted on their own.=C2=A0</div><di=
v><br></div><div>&gt; for payments to come with covenants but the recipient=
 not even be able to parse them unless they&#39;re fully buying into that b=
ehavior is much more reasonable.=C2=A0</div><div><br></div><div>The recipie=
nt not being able to parse them? Couldn&#39;t that result in exactly the si=
tuation above you said was not acceptable? The recipient must be able to kn=
ow all the possibilities of the covenant or there might be some secret retr=
oactive clawback in there waiting to bite them.</div><div><br></div><div><b=
r></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Fri, Dec 31, 2021 at 6:41 PM Bram Cohen via bitcoin-dev &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linu=
xfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr">There are a few different approaches to add=
ing covenants and capabilities to the UTXO model with varying tradeoffs. It=
 turns out that it can be done while making very few but not quite zero com=
promises to practices Bitcoin has been following so far.<div><br></div><div=
>First, the good news: Full support for both capabilities and covenants can=
 be added without changing the UTXO model whatsoever by adding some more pr=
ogrammatic capabilities to the language and doing some programmatic tricks.=
 Since scriptpubkeys/scriptsigs=C2=A0continue to run ephemerally at validat=
ion time full turing completeness is much less dangerous than people fear. =
The main thing missing from what&#39;s expressed in transactions themselves=
 is a coherent notion of a single parent of each output instead of the all-=
inputs-lead-to-all-outputs approach of transactions currently. It would als=
o probably be a good idea to add in a bunch of special purpose opcodes for =
making coherent statements about transactions since in Bitcoin they&#39;re =
a very complex and hard to parse format.</div><div><br></div><div>Now for t=
he controversial stuff. Once you start implementing complex general purpose=
 functionality it tends to get very expensive very fast and is likely impra=
ctical unless there&#39;s a way to compress or at least de-duplicate=C2=A0s=
nippets of code which are repeated on chain. Currently Bitcoin has a strong=
 policy that deciding which transactions to let into a block for maximum fe=
e is a strictly linear optimization problem and while it&#39;s possible to =
keep things mostly that way making it completely strict is unlikely to work=
able. About as close as you can get is to make it so that each block can re=
ference code snippets in previous blocks for deduplication, so at least the=
 optimization is linear for each block by itself.</div><div><br></div><div>=
Having covenants and capabilities at all is controversial in and of itself.=
 With covenants the main issue is whether they&#39;re opt-in or opt-out. Fo=
r 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 som=
e kind of retroactive veto on new action or even clawback would obviously b=
e unacceptable behavior. But for payments to come with covenants but the re=
cipient not even be able to parse them unless they&#39;re fully buying into=
 that behavior is much more reasonable.=C2=A0</div><div><br></div><div>The =
main issue which people have raised with capabilities is that if you were t=
o have colored coins whose value was substantially greater than the chain t=
hey were tokenized on then that could potentially create a business model f=
or attacking the underlying chain. While this is a real concern tokenized a=
ssets have been out for a while now and have never come close to causing th=
is to happen, so maybe people aren&#39;t so worried about it now.</div><div=
><br></div><div>Given all the above caveats it turns out one weird trick is=
 all you need to support general purpose capabilities: for a UTXO to have a=
 capability its scriptpubkey asserts that its parent must either be the ori=
ginator of that capability or also conform to the same parent-asserting for=
mat. More complex functionality such as supporting on-chain verifiable colo=
red coins can also be done but it follows the same pattern: Capabilities ar=
e implemented as backwards pointing covenants.</div><div><br></div><div>If =
you&#39;d like to see a fleshed out implementation of these ideas (albeit i=
n a slightly different model) there&#39;s quite a bit of stuff on <a href=
=3D"http://chialisp.com" target=3D"_blank">chialisp.com</a></div><div><br><=
/div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000ceb29105d5dcac8d--