path: root/aa/7828abd6618c75a8e49857b7fb17f44bb3daae

Return-Path: <bram@chia.net>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 306EFC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 02:55:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 17B9660615
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 02:55:12 +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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=chia.net
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id czG2ulGscd8F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 02:55:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com
 [IPv6:2a00:1450:4864:20::134])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 7F381606FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 02:55:10 +0000 (UTC)
Received: by mail-lf1-x134.google.com with SMTP id w12so1339157lfr.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 08 Mar 2022 18:55:10 -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=ZwvfbYp5/bXw/IKWx/2OJrgZJiyp7BV8pFEP1BHX1Es=;
 b=IsUJiyDBb9HoJkQ3Fb91Q5uBrSk5dq35PJrvKyY8tN/z6FWuWyW/wrvRsRMXnVumAU
 b6Ymya2ojGIsY/CscH0DU16EgjqT/FfyaP2WFUBA/NyqfDmjWO2R3j0QZTrQprbBAEOH
 Em0F9SDYellnisYVXn1TDsGAAI/9oiXwk+4A/911HDMUE35HqDCPn3WsIJ46dgEvM2lE
 /1MHnX9K9GR5bUUwWHEmsUuG7afDS3tgB5Au7d6K/B9pVideKWMwcfEBP1UzV/vCh/fF
 6yI1cb7HfoxR+rdXIOGUtjtCL3XrilrENmxh2HqSRUHxG5Knq/xvgJIXMoNbb0t7Bwdj
 aPZQ==
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=ZwvfbYp5/bXw/IKWx/2OJrgZJiyp7BV8pFEP1BHX1Es=;
 b=gWXQObk2H607CqfpGYaklXfJXqyXIsznSEtT7pypOhPLpRV2mz1uvY0imU+g8VJD4+
 Sr0hpl20Pd0NLqA73hFD0Zm3I9HiUlk1FhjY9XH0EpmJXVQhY5yeCzranxviYyNve5ik
 qQlsWObvSYn3+G7ja5xa5obiuQKFbqyH7vuTyEibIog0iPqGjQGfDpMCpglVRYguVGNe
 kptylSZkZc8g5altqkGObiz4kyt9JsFK1EbnoeyNdXoFtZqmu8sS0t1I8TRsn+naP72n
 Gw9dWuX+WOg+TwPI11y0Xj2cpWG1egu7j14JXlWs59m4HhRWlS/9VQL8bcUAbNtErOcM
 Fusg==
X-Gm-Message-State: AOAM533XT763sxve1xWS8chlzy/cYwjTFi4X+CjAWVwTNQnjgz7HMWiv
 tOIS5d0IH+KWjOPdsZX2TmIwOa2EBmjp1t3nJffhjw==
X-Google-Smtp-Source: ABdhPJy476MjKFCC7FUHb+STUqyrXtqjTX2nXSrNYgoHdvTIjtzfNBJzROzx7iC7ZyrwGsn2ezXF5E9Fc2IKpnSRLLM=
X-Received: by 2002:ac2:410d:0:b0:443:7f40:47a8 with SMTP id
 b13-20020ac2410d000000b004437f4047a8mr12459309lfi.228.1646794508006; Tue, 08
 Mar 2022 18:55:08 -0800 (PST)
MIME-Version: 1.0
References: <uOr9bwW2C0lwMSiUOEie2rzyrA7uE4Rm7kVnU2FnF9jyMGjYDvN0WhDM6QbZ_XxNlu44WqE7meXBZAeHAd94DAWnYcSBOPuo4nb4UQp2Wmk=@protonmail.com>
 <CAHUJnBCrw0n_9=2gugMhTW6QCjStBFxEsGrF=BY9JX806OurXQ@mail.gmail.com>
 <20220308012719.GA6992@erisian.com.au>
In-Reply-To: <20220308012719.GA6992@erisian.com.au>
From: Bram Cohen <bram@chia.net>
Date: Tue, 8 Mar 2022 18:54:56 -0800
Message-ID: <CAHUJnBDR-zQa0uBRorWkVf7CO+oS-J3zJU7B8K9cA_+7vqa=Dg@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="000000000000ab0a3b05d9c0398b"
X-Mailman-Approved-At: Wed, 09 Mar 2022 13:10:51 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin scripting and lisp
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: Wed, 09 Mar 2022 02:55:12 -0000

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

On Mon, Mar 7, 2022 at 5:27 PM Anthony Towns <aj@erisian.com.au> wrote:

> One way to match the way bitcoin do things, you could have the "list of
> extra conditions" encoded explicitly in the transaction via the annex,
> and then check the extra conditions when the script is executed.
>

The conditions are already basically what's in transactions. I think the
only thing missing is the assertion about one's own id, which could be
added in by, in addition to passing the scriptpubkey the transaction it's
part of, also passing in the index of inputs which it itself is.


>
> > If you're doing everything from scratch it's cleaner to go with the coin
> > set model, but retrofitting onto existing Bitcoin it may be best to leave
> > the UTXO model intact and compensate by adding a bunch more opcodes which
> > are special to parsing Bitcoin transactions. The transaction format
> itself
> > can be mostly left alone but to enable some of the extra tricks (mostly
> > implementing capabilities) it's probably a good idea to make new
> > conventions for how a transaction can have advisory information which
> > specifies which of the inputs to a transaction is the parent of a
> specific
> > output and also info which is used for communication between the UTXOs
> in a
> > transaction.
>
> I think the parent/child coin relationship is only interesting when
> "unrelated" spends can assert that the child coin is being created -- ie
> things along the lines of the "transaction sponsorship" proposal. My
> feeling is that complicates the mempool a bit much, so is best left for
> later, if done at all.
>

The parent/child relationship is mostly about implementing capabilities.
There's this fundamental trick, sort of the ollie of UTXO programming,
where to make a coin have a capability you have a wrapper around an inner
puzzle for it where the wrapper asserts 'my parent must either be the
unique originator of this capability or also have this same wrapper' and it
enforces that by being given a reveal of its parent and told/asserting its
own id which it can derive from that parent. The main benefit of the coin
set approach over UTXO is that it reduces the amount of stuff to be
revealed and string mangling involved in the parentage check.


>
> (I think the hard part of managing the extra conditions is mostly
> in keeping it efficient to manage the mempool and construct the most
> profitable blocks/bundles, rather than where the data goes)
>

Not sure what you mean by this. Conditions map fairly closely with what's
in Bitcoin transactions and are designed so to be monotonic and so the
costs and fees are known up front. The only way two transactions can
conflict with each other is if they both try to spend the same coin.


> > They're radically different approaches and
> > it's hard to see how they mix. Everything in lisp is completely
> sandboxed,
> > and that functionality is important to a lot of things, and it's really
> > normal to be given a reveal of a scriptpubkey and be able to rely on your
> > parsing of it.
>
> The above prevents combining puzzles/solutions from multiple coin spends,
> but I don't think that's very attractive in bitcoin's context, the way
> it is for chia. I don't think it loses much else?
>

Making something lisp-based be a completely alternative script type would
also be my preferred approach.


> > A nice side benefit of sticking with the UTXO model is that the soft fork
> > hook can be that all unknown opcodes make the entire thing automatically
> > pass.
>
> I don't think that works well if you want to allow the spender (the
> puzzle solution) to be able to use opcodes introduced in a soft-fork
> (eg, for graftroot-like behaviour)?
>

This is already the approach to soft forking in Bitcoin script and I don't
see anything wrong with it. You shouldn't write scripts using previously
unrecognized opcodes until after they've been soft forked into having real
functionality, and if you do that and accidentally write an anyonecanspend
that's your own fault.


> Having third parties be able to link their spends to yours complicates
> mempool behaviour a fair bit (see the discussions on pinning wrt
> lightning txs -- and that's only with direct participants being able to
> link transactions).


Bitcoin already has that with spending of transaction outputs, and Chia's
mempool doesn't currently let transactions depend on other transactions in
the mempool. If you do have that sort of dependency, you should have to
smush both transactions together to make a single larger transaction and
make it have enough of a fee to replace the smaller one.

I'm pretty skeptical about having a database of large script snippets
> that will hopefully be reused in the future.
>

That database is just the list of old blocks which can be dredged up to
have code pulled out of them.


> In chia the "scriptPubKey" is the hash of a lisp program, and when you
> create a new coin, the "scriptPubKey" of the newly generated coin is
> also the output of a lisp program. So writing a quine gets you general
> recursive covenants in a pretty straight forward way, as I understand it.
>

Usually you don't quite write a quine because you can be passed in your own
code and assert your own id derived from it, but that's the basic idea. You
need to validate your own id anyway when you have a capability.


> Rather than a "transaction" containing "inputs/outputs", chia has spend
> bundles that spend and create coins; and spend bundles can be merged
> together, so that a block only has a single spend bundle. That spend
> bundle joins all the puzzles (the programs that, when hashed match
> the scriptPubKey) and solutions (scriptSigs) for the coins being spent
> together.
>

I often refer to spend bundles as 'transactions'. Hope that isn't too
confusing. They serve the same function in the mempool.


>
> I /think/ the compression hook would be to allow you to have the puzzles
> be (re)generated via another lisp program if that was more efficient
> than just listing them out.


It literally has a lisp program called the generator which returns the list
of puzzle reveals and transactions. The simplest version of that program is
to return a quoted list.

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

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Mar 7, 2022 at 5:27 PM Anthony To=
wns &lt;<a href=3D"mailto:aj@erisian.com.au">aj@erisian.com.au</a>&gt; wrot=
e:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">One way to match the way bitcoin do things, you could have th=
e &quot;list of<br>
extra conditions&quot; encoded explicitly in the transaction via the annex,=
<br>
and then check the extra conditions when the script is executed.<br></block=
quote><div><br></div><div>The conditions are already basically what&#39;s i=
n transactions. I think the only thing missing is the assertion about one&#=
39;s own id, which could be added in by, in addition to passing the scriptp=
ubkey the transaction it&#39;s part of, also passing in the index of inputs=
 which it itself is.</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">
<br>
&gt; If you&#39;re doing everything from scratch it&#39;s cleaner to go wit=
h the coin<br>
&gt; set model, but retrofitting onto existing Bitcoin it may be best to le=
ave<br>
&gt; the UTXO model intact and compensate by adding a bunch more opcodes wh=
ich<br>
&gt; are special to parsing Bitcoin transactions. The transaction format it=
self<br>
&gt; can be mostly left alone but to enable some of the extra tricks (mostl=
y<br>
&gt; implementing capabilities) it&#39;s probably a good idea to make new<b=
r>
&gt; conventions for how a transaction can have advisory information which<=
br>
&gt; specifies which of the inputs to a transaction is the parent of a spec=
ific<br>
&gt; output and also info which is used for communication between the UTXOs=
 in a<br>
&gt; transaction.<br>
<br>
I think the parent/child coin relationship is only interesting when<br>
&quot;unrelated&quot; spends can assert that the child coin is being create=
d -- ie<br>
things along the lines of the &quot;transaction sponsorship&quot; proposal.=
 My<br>
feeling is that complicates the mempool a bit much, so is best left for<br>
later, if done at all.<br></blockquote><div><br></div><div>The parent/child=
 relationship is mostly about implementing capabilities. There&#39;s this f=
undamental trick, sort of the ollie of UTXO programming, where to make a co=
in have a capability you have a wrapper around an inner puzzle for it where=
 the wrapper asserts &#39;my parent must either be the unique originator of=
 this capability or also have this same wrapper&#39; and it enforces that b=
y being given a reveal of its parent and told/asserting its own id which it=
 can derive from that parent. The main benefit of the coin set approach ove=
r UTXO is that it reduces the amount of stuff to be revealed and string man=
gling involved in the parentage check.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">
<br>
(I think the hard part of managing the extra conditions is mostly<br>
in keeping it efficient to manage the mempool and construct the most<br>
profitable blocks/bundles, rather than where the data goes)<br></blockquote=
><div><br></div><div>Not sure what you mean by this. Conditions map fairly =
closely with what&#39;s in Bitcoin transactions and are designed so to be m=
onotonic and so the costs and fees are known up front. The only way two tra=
nsactions can conflict with each other is if they both try to spend the sam=
e coin.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">&gt; They&#39;re radically different approaches and<br>
&gt; it&#39;s hard to see how they mix. Everything in lisp is completely sa=
ndboxed,<br>
&gt; and that functionality is important to a lot of things, and it&#39;s r=
eally<br>
&gt; normal to be given a reveal of a scriptpubkey and be able to rely on y=
our<br>
&gt; parsing of it.<br>
<br>
The above prevents combining puzzles/solutions from multiple coin spends,<b=
r>
but I don&#39;t think that&#39;s very attractive in bitcoin&#39;s context, =
the way<br>
it is for chia. I don&#39;t think it loses much else?<br></blockquote><div>=
<br></div><div>Making something lisp-based be a completely alternative scri=
pt type would also be my preferred approach.</div><div>=C2=A0</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">&gt; A nice side benefit of stick=
ing with the UTXO model is that the soft fork<br>
&gt; hook can be that all unknown opcodes make the entire thing automatical=
ly<br>
&gt; pass.<br>
<br>
I don&#39;t think that works well if you want to allow the spender (the<br>
puzzle solution) to be able to use opcodes introduced in a soft-fork<br>
(eg, for graftroot-like behaviour)?<br></blockquote><div><br></div><div>Thi=
s is already the approach to soft forking in Bitcoin script and I don&#39;t=
 see anything wrong with it. You shouldn&#39;t write scripts using previous=
ly unrecognized opcodes until after they&#39;ve been soft forked into havin=
g real functionality, and if you do that and accidentally write an anyoneca=
nspend that&#39;s your own fault.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Having third parties be able to link their=
 spends to yours complicates<br>
mempool behaviour a fair bit (see the discussions on pinning wrt<br>
lightning txs -- and that&#39;s only with direct participants being able to=
<br>
link transactions).</blockquote><div><br></div><div>Bitcoin already has tha=
t with spending of transaction outputs, and Chia&#39;s mempool doesn&#39;t =
currently let transactions depend on other transactions in the mempool. If =
you do have that sort of dependency, you should have to smush both transact=
ions together to make a single larger transaction and make it have enough o=
f a fee to replace the smaller one.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">I&#39;m pretty skeptical about having a da=
tabase of large script snippets<br>
that will hopefully be reused in the future.<br></blockquote><div><br></div=
><div>That database is just the list of old blocks which can be dredged up =
to have code pulled out of them.</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">In chia the &quot;scriptPubKey&quot; is the h=
ash of a lisp program, and when you<br>
create a new coin, the &quot;scriptPubKey&quot; of the newly generated coin=
 is<br>
also the output of a lisp program. So writing a quine gets you general<br>
recursive covenants in a pretty straight forward way, as I understand it.<b=
r></blockquote><div><br></div><div>Usually you don&#39;t quite write a quin=
e because you can be passed in your own code and assert your own id derived=
 from it, but that&#39;s the basic idea. You need to validate your own id a=
nyway when you have a capability.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Rather than a &quot;transaction&quot; cont=
aining &quot;inputs/outputs&quot;, chia has spend<br>
bundles that spend and create coins; and spend bundles can be merged<br>
together, so that a block only has a single spend bundle. That spend<br>
bundle joins all the puzzles (the programs that, when hashed match<br>
the scriptPubKey) and solutions (scriptSigs) for the coins being spent<br>
together.<br></blockquote><div><br></div><div>I often refer to spend bundle=
s as &#39;transactions&#39;. Hope that isn&#39;t too confusing. They serve =
the same function in the mempool.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<br>
I /think/ the compression hook would be to allow you to have the puzzles<br=
>
be (re)generated via another lisp program if that was more efficient<br>
than just listing them out.</blockquote><div><br></div><div>It literally ha=
s a lisp program called the generator which returns the list of puzzle reve=
als and transactions. The simplest version of that program is to return a q=
uoted list.</div></div></div>

--000000000000ab0a3b05d9c0398b--