From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Bram Cohen <bram@chia•net>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin scripting and lisp
Date: Mon, 07 Mar 2022 22:56:38 +0000 [thread overview]
Message-ID: <uOr9bwW2C0lwMSiUOEie2rzyrA7uE4Rm7kVnU2FnF9jyMGjYDvN0WhDM6QbZ_XxNlu44WqE7meXBZAeHAd94DAWnYcSBOPuo4nb4UQp2Wmk=@protonmail.com> (raw)
In-Reply-To: <CAHUJnBCrw0n_9=2gugMhTW6QCjStBFxEsGrF=BY9JX806OurXQ@mail.gmail.com>
Good morning Bram,
> 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?
> > - serialization seems to be a bit verbose -- 100kB of serialized clvm
> > code from a random block gzips to 60kB; optimising the serialization
> > for small lists, and perhaps also for small literal numbers might be
> > a feasible improvement; though it's not clear to me how frequently
> > serialization size would be the limiting factor for cost versus
> > execution time or memory usage.
>
> 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?
> > 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 SCRIPT.
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
next prev parent reply other threads:[~2022-03-07 22:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.30513.1646355894.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-03-07 6:26 ` Bram Cohen
2022-03-07 22:56 ` ZmnSCPxj [this message]
2022-03-09 2:24 ` Bram Cohen
2022-03-08 1:27 ` Anthony Towns
2022-03-08 3:06 ` ZmnSCPxj
2022-03-09 3:07 ` Bram Cohen
2022-03-09 14:30 ` ZmnSCPxj
2022-03-16 6:40 ` Bram Cohen
2022-03-16 15:09 ` ZmnSCPxj
2022-03-11 4:46 ` Anthony Towns
2022-03-16 6:52 ` Bram Cohen
2022-03-16 14:54 ` ZmnSCPxj
2022-03-19 17:34 ` Bram Cohen
2022-03-22 23:37 ` Anthony Towns
2022-03-09 2:54 ` Bram Cohen
2022-03-10 6:47 ` Anthony Towns
2022-03-16 6:45 ` Bram Cohen
2022-03-04 1:04 Anthony Towns
2022-03-04 23:10 ` ZmnSCPxj
[not found] ` <CAD5xwhiZx+dp46Gn23tQRKc5PgJHmaJ_HC-38VB5WdJjWVVc4g@mail.gmail.com>
2022-03-05 13:41 ` Jeremy Rubin
2022-03-05 20:10 ` Russell O'Connor
2022-03-05 23:20 ` ZmnSCPxj
2022-03-06 2:09 ` Russell O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='uOr9bwW2C0lwMSiUOEie2rzyrA7uE4Rm7kVnU2FnF9jyMGjYDvN0WhDM6QbZ_XxNlu44WqE7meXBZAeHAd94DAWnYcSBOPuo4nb4UQp2Wmk=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bram@chia$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox