MIME-Version: 1.0
References: <mailman.30513.1646355894.8511.bitcoin-dev@lists.linuxfoundation.org>
 <CAHUJnBCrw0n_9=2gugMhTW6QCjStBFxEsGrF=BY9JX806OurXQ@mail.gmail.com>
 <uOr9bwW2C0lwMSiUOEie2rzyrA7uE4Rm7kVnU2FnF9jyMGjYDvN0WhDM6QbZ_XxNlu44WqE7meXBZAeHAd94DAWnYcSBOPuo4nb4UQp2Wmk=@protonmail.com>
In-Reply-To: <uOr9bwW2C0lwMSiUOEie2rzyrA7uE4Rm7kVnU2FnF9jyMGjYDvN0WhDM6QbZ_XxNlu44WqE7meXBZAeHAd94DAWnYcSBOPuo4nb4UQp2Wmk=@protonmail.com>
From: Bram Cohen <bram@chia.net>
Date: Tue, 8 Mar 2022 18:24:15 -0800
Message-ID: <CAHUJnBAax+2jJtoxLQ009hz_exqVNajGt2UUHp1hvpGUKCyXoA@mail.gmail.com>
To: ZmnSCPxj <zmnscpxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000eccf9305d9bfcbd9"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin scripting and lisp
Precedence: list

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

On Mon, Mar 7, 2022 at 2:56 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

>
> > while in the coin set model each puzzle (scriptpubkey) gets run and
> either assert fails or returns a list of extra conditions it has, possibly
> including timelocks and creating new coins, paying fees, and other things.
>
> Does this mean it basically gets recursive covenants?
> Or is a condition in this list of conditions written a more restrictive
> language which itself cannot return a list of conditions?
>

The conditions language is extremely restrictive but does allow for
recursive covenants through the route of specifying output
scriptpubkeys/puzzles, which Bitcoin already sort of in principle supports
except that Bitcoin script's ability to generate and parse transactions
isn't quite up to the task.


> > A lot of this is because there's a hook for doing compression at the
> consensus layer which isn't being used aggressively yet. That one has the
> downside that the combined cost of transactions can add up very
> nonlinearly, but when you have constantly repeated bits of large
> boilerplate it gets close and there isn't much of an alternative. That said
> even with that form of compression maxxed out it's likely that gzip could
> still do some compression but that would be better done in the database and
> in wire protocol formats rather than changing the format which is hashed at
> the consensus layer.
>
> How different is this from "jets" as proposed in Simplicity?
>

My vague impression is that Simplicity jets are meant to be for things like
Sha3 rather than shared library code. It might be that the way to use it
would be to implement CLVM opcodes be a bunch of Simplicity jets. Whether
that would be making the CLVM irrelevant or going through a pointless bit
of theatre to be based on Simplicity under the hood I don't know.

The compression hook is that in each block instead of there being a list of
puzzle reveals and solutions there's a generator written in CLVM which
outputs that list, and it can be passed the generators of old blocks from
which it can pull out code snippits.

--000000000000eccf9305d9bfcbd9
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 2:56 PM ZmnSCPxj &=
lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&g=
t; wrote:<br></div><div class=3D"gmail_quote"><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"><br>
&gt; while in the coin set model each puzzle (scriptpubkey) gets run and ei=
ther assert fails or returns a list of extra conditions it has, possibly in=
cluding timelocks and creating new coins, paying fees, and other things.<br=
>
<br>
Does this mean it basically gets recursive covenants?<br>
Or is a condition in this list of conditions written a more restrictive lan=
guage which itself cannot return a list of conditions?<br></blockquote><div=
><br></div><div>The conditions language is extremely restrictive but does a=
llow for recursive covenants through the route of specifying output scriptp=
ubkeys/puzzles, which Bitcoin already sort of in principle supports except =
that Bitcoin script&#39;s ability to generate and parse transactions isn=
9;t quite up to the task.</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">&gt; A lot of this is because there&#39;s a hook for=
 doing compression at the consensus layer which isn&#39;t being used aggres=
sively yet. That one has the downside that the combined cost of transaction=
s can add up very nonlinearly, but when you have constantly repeated bits o=
f large boilerplate it gets close and there isn&#39;t much of an alternativ=
e. That said even with that form of compression maxxed out it&#39;s likely =
that gzip could still do some compression but that would be better done in =
the database and in wire protocol formats rather than changing the format w=
hich is hashed at the consensus layer.<br>
<br>
How different is this from &quot;jets&quot; as proposed in Simplicity?<br><=
/blockquote><div><br></div><div>My vague impression is that Simplicity jets=
 are meant to be for things like Sha3 rather than shared library code. It m=
ight be that the way to use it would be to implement CLVM opcodes be a bunc=
h of Simplicity jets. Whether that would be making the CLVM irrelevant or g=
oing through a pointless bit of theatre to be based on Simplicity under the=
 hood I don&#39;t know.</div><div><br></div><div>The compression hook is th=
at in each block instead of there being a list of puzzle reveals and soluti=
ons there&#39;s a generator written in CLVM which outputs that list, and it=
 can be passed the generators of old blocks from which it can pull out code=
 snippits.</div><div><br></div></div></div>

--000000000000eccf9305d9bfcbd9--