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 E2585C000B for ; Wed, 9 Mar 2022 02:24:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id C8D3840103 for ; Wed, 9 Mar 2022 02:24:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=chia.net 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 nT06zo2hvq9m for ; Wed, 9 Mar 2022 02:24:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by smtp2.osuosl.org (Postfix) with ESMTPS id 5796E400EA for ; Wed, 9 Mar 2022 02:24:29 +0000 (UTC) Received: by mail-lj1-x230.google.com with SMTP id r22so1140273ljd.4 for ; Tue, 08 Mar 2022 18:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OH1ob4ixb9t+gGryOY3/k81AVII9+T7y/7ROym6ejzE=; b=G4A7lNo72KqKqFk4SYfRFqC/Qw78GYc87k+qec2N9Zi1mpANFvPs7yipMopsNdjhQD LQ8Ggp6+LeUa3T+V9jFAV2L5r9NTa7+GZINVs72bdmhXYzwDjZo8eMyRy0wewRK+dT/O BR+S3NDTDDcbLrxuAHUNdmRwl5vuRtXpRCON5mpm8K3xuYgDJxY1S5YUA/d564pG+0R9 Cj+3zkE4395CWWUG5XfQsfkordyurw7tOIDdnPbSVJVsxwH6mRNQA9GgbXD0Jz0ZRkvM wk485XMJKEqqqFlRv7rK08d8Ct8m8LVsHgjRWwpDCWwkOKILm5apY7Bj43kN2jedaIPt jZqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OH1ob4ixb9t+gGryOY3/k81AVII9+T7y/7ROym6ejzE=; b=j6wl2xUB97axtCJWZ8TCxZyXBq0J9sHmKofOoXDzSMb76eQr4qbJhKz0nSqxB+rmiV TYulK7/Zo3iDo4Z8IAE3VO8gPe20hhMYcZ0AO0op03GZtnm1rOnQOfh9APMWdaQ7RXRB s8dD3Us62pzFJLeG3Rte5h0cR9Yo2g4n+kr7/reLuNne86Rk5PEC2SOpZUTM94D8FuBg 6pdP2dTjrZy3o11HRJ3N8CdnDuK4El1gh04TohI6FBtcCgIDvaWr4nrNeG4ks/HWjLO3 tlXv/EJjvTh/4L9pu9Cxbr4l7jWNGB4wX+2LfR5Swoj2v4FOHQjwtQZjXIMy7blm+ayX +QMQ== X-Gm-Message-State: AOAM531KX6btHKztw7oE4Btd5kSQWIZltfGCkSt7S4HjzKV4yaK07dLH x/Y5zgqBBABScDH6kIRQd0S3rI4VySWb4xM7VAjX4A== X-Google-Smtp-Source: ABdhPJwJh6mNr02KJxu1zsUNxgUSAPQOrFysZr7WR9rVzhfaGKKHU0QnffzDPUw8wqZeT0g4YKOLV+ht+dXHXdNZbmA= X-Received: by 2002:a2e:7d05:0:b0:247:ed41:690d with SMTP id y5-20020a2e7d05000000b00247ed41690dmr4512004ljc.92.1646792666815; Tue, 08 Mar 2022 18:24:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Bram Cohen Date: Tue, 8 Mar 2022 18:24:15 -0800 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000eccf9305d9bfcbd9" X-Mailman-Approved-At: Wed, 09 Mar 2022 13:10:51 +0000 Cc: Bitcoin Protocol Discussion 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: Wed, 09 Mar 2022 02:24:35 -0000 --000000000000eccf9305d9bfcbd9 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 7, 2022 at 2:56 PM ZmnSCPxj 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
On Mon, Mar 7, 2022 at 2:56 PM ZmnSCPxj &= lt;ZmnSCPxj@protonmail.com&g= t; wrote:

> 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.
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?

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's ability to generate and parse transactions isn= 9;t quite up to the task.
=C2=A0
> A lot of this is because there's a hook for= doing compression at the consensus layer which isn'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't much of an alternativ= e. 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 w= hich is hashed at the consensus layer.

How different is this from "jets" as proposed in Simplicity?
<= /blockquote>

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't know.

The compression hook is th= at in each block instead of there being a list of puzzle reveals and soluti= ons 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--