From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9EB31C002F for ; 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 ; 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 ; 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 ; Tue, 18 Jan 2022 17:16:39 +0000 (UTC) Received: by mail-lf1-x133.google.com with SMTP id m1so73550825lfq.4 for ; 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: In-Reply-To: From: Bram Cohen Date: Tue, 18 Jan 2022 09:16:25 -0800 Message-ID: To: Billy Tetrud Content-Type: multipart/alternative; boundary="000000000000828ccb05d5de6e24" X-Mailman-Approved-At: Tue, 18 Jan 2022 19:14:53 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
On Tue, Jan 18, 2022 at 7:10 AM Billy Tet= rud <billy.tetrud@gmail.com> wrote:

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 depend= encies declared up front execution can be made completely deterministic.

=C2=A0> 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're a very complex and hard to pa= rse format.

What are some examples you're thinking of?=

What's needed from a progr= amming perspective is the ability to say 'assert that my parent has a s= criptpubkey of X'. 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 ('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 typ= e of scriptpubkey. This allows capabilities to be added without gunking up = on chain state with things other than UTXOs.

=C2=A0

> Once you start imple= menting complex general purpose functionality it tends to get very expensiv= e very fast and is likely impractical unless there's a way to compress = or at least de-duplicate=C2=A0snippets of code which are repeated on chain.=

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's stored in the softw= are 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 cha= nged by this approach.=C2=A0

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 'common sections'= up front. Charging for virtual vbytes unfortunately keeps smart functional= ity very expensive and the point is to make it not so expensive.
= =C2=A0
> 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.

I def= initely agree. A payment's covenant should be completely knowable to th= e recipient, and recipients shouldn't accept random covenants they have= n't explicitly accepted on their own.=C2=A0

&g= t; for payments to come with covenants but the recipient not even be able t= o parse them unless they're fully buying into that behavior is much mor= e reasonable.=C2=A0

The recipient not being able t= o parse them? Couldn'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.

No= t 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--