Date: Mon, 07 Mar 2022 22:56:38 +0000
To: Bram Cohen <bram@chia.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <uOr9bwW2C0lwMSiUOEie2rzyrA7uE4Rm7kVnU2FnF9jyMGjYDvN0WhDM6QbZ_XxNlu44WqE7meXBZAeHAd94DAWnYcSBOPuo4nb4UQp2Wmk=@protonmail.com>
In-Reply-To: <CAHUJnBCrw0n_9=2gugMhTW6QCjStBFxEsGrF=BY9JX806OurXQ@mail.gmail.com>
References: <mailman.30513.1646355894.8511.bitcoin-dev@lists.linuxfoundation.org>
 <CAHUJnBCrw0n_9=2gugMhTW6QCjStBFxEsGrF=BY9JX806OurXQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] bitcoin scripting and lisp
Precedence: list

Good morning Bram,

> while in the coin set model each puzzle (scriptpubkey) gets run and eithe=
r assert fails or returns a list of extra conditions it has, possibly inclu=
ding 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 lan=
guage which itself cannot return a list of conditions?


> > =C2=A0- serialization seems to be a bit verbose -- 100kB of serialized =
clvm
> > =C2=A0 =C2=A0code from a random block gzips to 60kB; optimising the ser=
ialization
> > =C2=A0 =C2=A0for small lists, and perhaps also for small literal number=
s might be
> > =C2=A0 =C2=A0a feasible improvement; though it's not clear to me how fr=
equently
> > =C2=A0 =C2=A0serialization size would be the limiting factor for cost v=
ersus
> > =C2=A0 =C2=A0execution time or memory usage.
>
> A lot of this is because there's a hook for doing compression at the cons=
ensus layer which isn't being used aggressively yet. That one has the downs=
ide 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 co=
mpression 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?

> > Pretty much all the opcodes in the first section are directly from chia
> > lisp, while all the rest are to complete the "bitcoin" functionality.
> > The last two are extensions that are more food for thought than a real
> > proposal.
>
> Are you thinking of this as a completely alternative script format or an =
extension to bitcoin script? 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.

I believe AJ is proposing a completely alternative format to OG Bitcoin SCR=
IPT.
Basically, as I understand it, nothing in the design of Tapscript versions =
prevents us from completely changing the interpretation of Tapscript bytes,=
 and use a completely different language.
That is, we could designate a new Tapscript version as completely different=
 from OG Bitcoin SCRIPT.


Regards,
ZmnSCPxj