+Return-Path: <aj@erisian.com.au>

+Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])

+ by lists.linuxfoundation.org (Postfix) with ESMTP id AA6FBC000B

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Fri, 11 Mar 2022 04:46:58 +0000 (UTC)

+Received: from localhost (localhost [127.0.0.1])

+ by smtp4.osuosl.org (Postfix) with ESMTP id 93A9A419B1

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Fri, 11 Mar 2022 04:46:58 +0000 (UTC)

+X-Virus-Scanned: amavisd-new at osuosl.org

+X-Spam-Flag: NO

+X-Spam-Score: -0.415

+X-Spam-Level:

+X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5

+ tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, SPF_HELO_PASS=-0.001,

+ SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001]

+ autolearn=ham autolearn_force=no

+Received: from smtp4.osuosl.org ([127.0.0.1])

+ by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)

+ with ESMTP id Hw4GgFnzQrKg

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Fri, 11 Mar 2022 04:46:57 +0000 (UTC)

+X-Greylist: from auto-whitelisted by SQLgrey-1.8.0

+Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])

+ by smtp4.osuosl.org (Postfix) with ESMTPS id 8376A4199F

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Fri, 11 Mar 2022 04:46:57 +0000 (UTC)

+Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)

+ by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))

+ id 1nSXAw-0003WM-KP; Fri, 11 Mar 2022 14:46:52 +1000

+Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);

+ Fri, 11 Mar 2022 14:46:45 +1000

+Date: Fri, 11 Mar 2022 14:46:45 +1000

+From: Anthony Towns <aj@erisian.com.au>

+To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,

+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>

+Message-ID: <20220311044645.GB7597@erisian.com.au>

+MIME-Version: 1.0

+Content-Type: text/plain; charset=us-ascii

+Content-Disposition: inline

+In-Reply-To: <lMd2d3ntj6T-VfDDZ0SHn7cUdWWeFFWO3sHolPwMTdRyGUMRY8JwtICT0vbNy9PPg-u_inUplQ-OvB-wKvXNkEUB17pXBhA7ZDwu9vxiRx0=@protonmail.com>

+ <NYPPZ7B4S9BQluVvyYLm7iBlBqmni5jOUYTqLtyZjCcSblwHhpXdbL5DQ4tmPVrI7eaIfdCB3d_MzQpbdD0Zdo-AvmpUbqs0JSpdB_R8nPE=@protonmail.com>

+User-Agent: Mutt/1.10.1 (2018-07-13)

+X-Spam-Score-int: -3

+X-Spam-Bar: /

+Cc: 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: Fri, 11 Mar 2022 04:46:58 -0000

+

+On Tue, Mar 08, 2022 at 03:06:43AM +0000, ZmnSCPxj via bitcoin-dev wrote:

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

+> > 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 puzzle/solution compression.

+

+Signature aggregation has a lot more maths and crypto involved than

+reversible compression of puzzles/solutions. I was more meaning

+cross-transaction relationships rather than cross-input ones though.

+

+> > 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 cryptocurrency node software, so "special C function" seems to overprivilege C...

+

+Jets are "special" in so far as they are costed differently at the

+consensus level than the equivalent pure/jetless simplicity code that

+they replace. Whether they're written in C or something else isn't the

+important part.

+

+By comparison, generating lisp code with lisp code in chia doesn't get

+special treatment.

+

+(You *could* also use jets in a way that doesn't impact consensus just

+to make your node software more efficient in the normal case -- perhaps

+via a JIT compiler that sees common expressions in the blockchain and

+optimises them eg)

+

+On Wed, Mar 09, 2022 at 02:30:34PM +0000, ZmnSCPxj via bitcoin-dev wrote:

+> Do note that PTLCs remain more space-efficient though, so forget about HTLCs and just use PTLCs.

+

+Note that PTLCs aren't really Chia-friendly, both because chia doesn't

+have secp256k1 operations in the first place, but also because you can't

+do a scriptless-script because the information you need to extract

+is lost when signatures are non-interactively aggregated via BLS --

+so that adds an expensive extra ECC operation rather than reusing an

+op you're already paying for (scriptless script PTLCs) or just adding

+a cheap hash operation (HTLCs).

+

+(Pretty sure Chia could do (= PTLC (pubkey_for_exp PREIMAGE)) for

+preimage reveal of BLS PTLCs, but that wouldn't be compatible with

+bitcoin secp256k1 PTLCs. You could sha256 the PTLC to save a few bytes,

+but I think given how much a sha256 opcode costs in Chia, that that

+would actually be more expensive?)

+

+None of that applies to a bitcoin implementation that doesn't switch to

+BLS signatures though.

+

+> > But if they're fully baked into the scriptpubkey then they're opted into by the recipient and there aren't any weird surprises.

+> This is really what I kinda object to.

+> Yes, "buyer beware", but consider that as the covenant complexity increases, the probability of bugs, intentional or not, sneaking in, increases as well.

+> And a bug is really "a weird surprise" --- xref TheDAO incident.

+

+Which is better: a bug in the complicated script code specified for

+implementing eltoo in a BOLT; or a bug in the BIP/implementation of a

+new sighash feature designed to make it easy to implement eltoo, that's

+been soft-forked into consensus?

+

+Seems to me, that it's always better to have the bug be at the wallet

+level, since that can be fixed by upgrading individual wallet software.

+

+> This makes me kinda wary of using such covenant features at all, and if stuff like `SIGHASH_ANYPREVOUT` or `OP_CHECKTEMPLATEVERIFY` are not added but must be reimplemented via a covenant feature, I would be saddened, as I now have to contend with the complexity of covenant features and carefully check that `SIGHASH_ANYPREVOUT`/`OP_CHECKTEMPLATEVERIFY` were implemented correctly.

+> True I also still have to check the C++ source code if they are implemented directly as opcodes, but I can read C++ better than frikkin Bitcoin SCRIPT.

+

+If OP_CHECKTEMPLATEVERIFY (etc) is implemented as a consensus update, you

+probably want to review the C++ code even if you're not going to use it,

+just to make sure consensus doesn't end up broken as a result. Whereas if

+it's only used by other people's wallets, you might be able to ignore it

+entirely (at least until it becomes so common that any bugs might allow

+a significant fraction of BTC to be stolen/lost and indirectly cause a

+systemic risk).

+

+> Not to mention that I now have to review both the (more complicated due to more general) covenant feature implementation, *and* the implementation of `SIGHASH_ANYPREVOUT`/`OP_CHECKTEMPLATEVERIFY` in terms of the covenant feature.

+

+I'm not sure that a "covenant language implementation" would necessarily

+be "that" complicated. And if so, having a DSL for covenants could,

+at least in theory, make for a much simpler implementation of

+ANYPREVOUT/CTV/TLUV/EVICT/etc than doing it directly in C++, which

+might mean those things are less likely to have "weird surprises" rather

+than more.

+

+Cheers,

+aj

+

+