path: root/f8/46c068af4f3bfe9b4bb2bbe36061c9c7e19d7f

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5B846C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <aj@erisian.com.au>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <NYPPZ7B4S9BQluVvyYLm7iBlBqmni5jOUYTqLtyZjCcSblwHhpXdbL5DQ4tmPVrI7eaIfdCB3d_MzQpbdD0Zdo-AvmpUbqs0JSpdB_R8nPE=@protonmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>,
 Bram Cohen <bram@chia.net>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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