Date: Wed, 16 Mar 2022 15:09:15 +0000
To: Bram Cohen <bram@chia.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <r7k8CLHeQWSZPQkQp8LVVYSaFNZ0IHRW3OlGTvB_XO9QCKrD5rg3Ek6lZoVN_qvBkXvIjy3e73FchagrRQpDjLXkNQRNUlcm8AkjjF1VijQ=@protonmail.com>
In-Reply-To: <CAHUJnBDMGmay0TYwzV87AaVQuGWoVG0s5vf+K6PikGN7sesxJQ@mail.gmail.com>
References: <20220308012719.GA6992@erisian.com.au>
 <NYPPZ7B4S9BQluVvyYLm7iBlBqmni5jOUYTqLtyZjCcSblwHhpXdbL5DQ4tmPVrI7eaIfdCB3d_MzQpbdD0Zdo-AvmpUbqs0JSpdB_R8nPE=@protonmail.com>
 <CAHUJnBBduZA9KgcYwEG7Zn3qPrBpnCRWukQpPzJJjpb3S933Ag@mail.gmail.com>
 <lMd2d3ntj6T-VfDDZ0SHn7cUdWWeFFWO3sHolPwMTdRyGUMRY8JwtICT0vbNy9PPg-u_inUplQ-OvB-wKvXNkEUB17pXBhA7ZDwu9vxiRx0=@protonmail.com>
 <CAHUJnBDMGmay0TYwzV87AaVQuGWoVG0s5vf+K6PikGN7sesxJQ@mail.gmail.com>
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>,
 Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] bitcoin scripting and lisp
Precedence: list

Good morning Bram,

> On Wed, Mar 9, 2022 at 6:30 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> > I am pointing out that:
> >
> > * We want to save bytes by having multiple inputs of a transaction use =
the same single signature (i.e. sigagg).
> >
> > is not much different from:
> >
> > * We want to save bytes by having multiple inputs of a transaction use =
the same `scriptPubKey` template.
>
> Fair point. In the past Bitcoin has been resistant to such things because=
 for example reusing pubkeys can save you from having to separately pay for=
 the reveals of all of them but letting people get credit for that incentiv=
izes key reuse which isn't such a great thing.

See paragraph below:

> > > > For example you might have multiple HTLCs, with mostly the same cod=
e except for details like who the acceptor and offerrer are, exact hash, an=
d timelock, 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 pro=
tocols use the same code for implementing HTLC.

Note that the acceptor and offerrer are represented by pubkeys here.
So we do not want to encourage key reuse, we want to encourage reuse of *ho=
w* the pubkeys are used (but rotate the pubkeys).

In the other thread on Jets in bitcoin-dev I proposed moving data like pubk=
eys into a separate part of the SCRIPT in order to (1) not encourage key re=
use and (2) make it easier to compress the code.
In LISP terms, it would be like requiring that top-level code have a `(let =
...)` form around it where the assigned data *must* be constants or `quote`=
, and disallowing constants and `quote` elsewhere, then any generated LISP =
code has to execute in the same top-level environment defined by this top-l=
evel `let`.

So you can compress the code by using some metaprogramming where LISP gener=
ates LISP code but you still need to work within the confines of the availa=
ble constants.

> > > HTLCs, at least in Chia, have embarrassingly=C2=A0little code in them=
. Like, so little that there's almost nothing to compress.
> >
> > In Bitcoin at least an HTLC has, if you remove the `OP_PUSH`es, by my c=
ount, 13 bytes.
> > If you have a bunch of HTLCs you want to claim, you can reduce your wit=
ness data by 13 bytes minus whatever number of bytes you need to indicate t=
his.
> > That amounts to about 3 vbytes per HTLC, which can be significant enoug=
h to be worth it (consider that Taproot moving away from encoded signatures=
 saves only 9 weight units per signature, i.e. about 2 vbytes).
>
> Oh I see. That's already extremely small overhead. When you start optimiz=
ing at that level you wind up doing things like pulling all the HTLCs into =
the same block to take the overhead of pulling in the template only once.
> =C2=A0
>
> > Do note that PTLCs remain more space-efficient though, so forget about =
HTLCs and just use PTLCs.
>
> It makes a lot of sense to make a payment channel system using PTLCs and =
eltoo right off the bat but then you wind up rewriting everything from scra=
tch.

Bunch of #reckless devs implemented Lightning with just HTLCs so that is th=
at, *shrug*, gotta wonder what those people were thinking, not waiting for =
PTLCs.

> =C2=A0
>
> > > > This does not apply to current Bitcoin since we no longer accept a =
SCRIPT from the spender, we now have a witness stack.
> > >
> > > My mental model of Bitcoin is to pretend that segwit was always there=
 and the separation of different sections of data is a semantic quibble.
> >
> > This is not a semantic quibble --- `witness` contains only the equivale=
nt of `OP_PUSH`es, while `scriptSig` can in theory contain non-`OP_PUSH` op=
codes.
> > xref. `1 RETURN`.
>
> It's very normal when you're using lisp for snippets of code to be passed=
 in as data and then verified and executed. That's enabled by the extreme a=
dherence to no side effects.

Quining still allows Turing-completeness and infinite loops, which *is* sti=
ll a side effect, though as I understand it ChiaLISP uses the "Turing-compl=
ete but with a max number of ops" kind of totality.

> > 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.
>
> Even the 'standard format' transaction which supports taproot and graftro=
ot is implemented in CLVM. The benefit of this approach is that new functio=
nality can be implemented and deployed immediately rather than having to pa=
instakingly go through a soft fork deployment for each thing.

Wow, just wow.

Regards,
ZmnSCPxj