From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id C2665C000B for ; Mon, 7 Mar 2022 22:56:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id AA85B4013A for ; Mon, 7 Mar 2022 22:56:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VNv5CRMXkAK for ; Mon, 7 Mar 2022 22:56:48 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by smtp2.osuosl.org (Postfix) with ESMTPS id 445CC400C1 for ; Mon, 7 Mar 2022 22:56:48 +0000 (UTC) Date: Mon, 07 Mar 2022 22:56:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1646693805; bh=JlSn7dN2VnMOC7yiLkkA/HHCrNBoOZDGapgFticawig=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: From:To:Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID; b=huc8dZKQfFPVhCu7iKKPOHQUOVnv6U90UDP8KUHx8Li5Pcgz/8C+hDPl2eGTS2iSM oNzMcKJ+qlorPovioyfiIdu3HD3YlxIIQmDGInBBzJjNpUOx/TJZrrTbfNOus0ADig Vz7btef2XwdfPDbnRCpYHB+oWXz7cg//nqFZxKxRE9E+QXKJnwkUVDHiHwRNN5zt4t eqsAO1XQGm8IfVXJrcZ60ZFqWclx49O7t/08v+2Urcys6aPE1KoNDNVvi5Y3LXbLeX 9xX++1qpJe0+ZOQLz7xedLKNkcTG5CVFBQBAHTaHd16Qf4tIh4DfFNQKrvfDkctvES VR/YSWmd84PQQ== To: Bram Cohen , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 22:56:49 -0000 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