From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5B846C000B for ; Tue, 8 Mar 2022 03:06:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3CE77828B5 for ; Tue, 8 Mar 2022 03:06:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVZJMX8gcaVz for ; Tue, 8 Mar 2022 03:06:52 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) by smtp1.osuosl.org (Postfix) with ESMTPS id 5136C828A9 for ; Tue, 8 Mar 2022 03:06:52 +0000 (UTC) Date: Tue, 08 Mar 2022 03:06:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1646708809; bh=8stdV9xkf1OIiYJXyMH1J3t3wXaxbwRWXp/5hfae/Jc=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=M1MBFBe0g9Cv+nNr9w/cBa0wCpr8fCTuNOjdseA4506rINcTw2ZN29ZUwmNExoqRv GWric/1QCSgzJmqpleXY4SJ1+cW7giS1Hx0wCeCnKNxqxTmPu4SHaUrMtGFWs5zAv9 JgP4JZ8855yoOs/XM3/z5GlovqFzKUZzX7AGR3HTgvMxEtSb6y20JBKdU20gnMeswb xBO1/Z1oGSX/EkatoFApQAw/9pAlHlvlxyEDOs3DnDmkpTMcm090RyaNyL9XdUEgCS mx3eX08n/LSuuDAkM/C7LoS2Rug+pIfS7EOr4wjN10i+p7rL2xEiQocw/uWK55tZJw w6Vy/9ofL9KZw== To: Anthony Towns From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <20220308012719.GA6992@erisian.com.au> References: <20220308012719.GA6992@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion , Bram Cohen 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: Tue, 08 Mar 2022 03:06:55 -0000 Good morning aj et al., > > They're radically different approaches and > > it's hard to see how they mix. Everything in lisp is completely sandbox= ed, > > 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 yo= ur > > 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? But cross-input signature aggregation is a nice-to-have we want for Bitcoin= , and, to me, cross-input sigagg is not much different from cross-input puz= zle/solution compression. For example you might have multiple HTLCs, with mostly the same code except= for details like who the acceptor and offerrer are, exact hash, and timelo= ck, and you could claim multiple HTLCs in a single tx and feed the details = separately but the code for the HTLC is common to all of the HTLCs. You do not even need to come from the same protocol if multiple protocols u= se the same code for implementing HTLC. > > > There's two ways to think about upgradability here; if someday we wan= t > > > to add new opcodes to the language -- perhaps something to validate z= ero > > > knowledge proofs or calculate sha3 or use a different ECC curve, or s= ome > > > way to support cross-input signature aggregation, or perhaps it's jus= t > > > that some snippets are very widely used and we'd like to code them in > > > C++ directly so they validate quicker and don't use up as much block > > > weight. One approach is to just define a new version of the language > > > via the tapleaf version, defining new opcodes however we like. > > > 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 automatica= lly > > > 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 does not apply to current Bitcoin since we no longer accept a SCRIPT f= rom the spender, we now have a witness stack. However, once we introduce opcodes that allow recursive covenants, it seems= this is now a potential footgun if the spender can tell the puzzle SCRIPT = to load some code that will then be used in the *next* UTXO created, and *t= hen* the spender can claim it. Hmmm.... Or maybe not? If the spender can already tell the puzzle SCRIPT to send the funds to a SC= RIPT that is controlled by the spender, the spender can already tell the pu= zzle SCRIPT to forward the funds to a pubkey the spender controls. So this seems to be more like "do not write broken SCRIPTs"? > > > > - serialization seems to be a bit verbose -- 100kB of serialized cl= vm > > > > =C2=A0 =C2=A0code from a random block gzips to 60kB; optimising the= serialization > > > > =C2=A0 =C2=A0for small lists, and perhaps also for small literal nu= mbers might be > > > > =C2=A0 =C2=A0a feasible improvement; though it's not clear to me ho= w frequently > > > > =C2=A0 =C2=A0serialization size would be the limiting factor for co= st versus > > > > =C2=A0 =C2=A0execution time or memory usage. > > > > A lot of this is because there's a hook for doing compression at th= e consensus layer which isn't being used aggressively yet. That one has the= downside that the combined cost of transactions can add up very nonlinearl= y, 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 compre= ssion but that would be better done in the database and in wire protocol fo= rmats rather than changing the format which is hashed at the consensus laye= r. > > > > How different is this from "jets" as proposed in Simplicity? > > 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 /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. But I assume it would be turtles, err, > lisp all the way down, no special C functions like with jets. Eh, you could use Common LISP or a recent-enough RnRS Scheme to write a cry= ptocurrency node software, so "special C function" seems to overprivilege C= ... I suppose the more proper way to think of this is that jets are *equivalent= to* some code in the hosted language, and have an *efficient implementatio= n* in the hosting language. In this view, the current OG Bitcoin SCRIPT is the hosted language, and the= C++ Bitcoin Core interpreter for it is in the hosting language C++. LISP can be both the hosted and hosting language because it is easy to impl= ement `eval` in LISP and you can write macros which transform small code sn= ippets into larger code. LISP code generating *more* LISP code is pretty much what macros are. Regards, ZmnSCPxj