Date: Wed, 09 Mar 2022 14:30:34 +0000
To: Bram Cohen <bram@chia.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <lMd2d3ntj6T-VfDDZ0SHn7cUdWWeFFWO3sHolPwMTdRyGUMRY8JwtICT0vbNy9PPg-u_inUplQ-OvB-wKvXNkEUB17pXBhA7ZDwu9vxiRx0=@protonmail.com>
In-Reply-To: <CAHUJnBBduZA9KgcYwEG7Zn3qPrBpnCRWukQpPzJJjpb3S933Ag@mail.gmail.com>
References: <20220308012719.GA6992@erisian.com.au>
 <NYPPZ7B4S9BQluVvyYLm7iBlBqmni5jOUYTqLtyZjCcSblwHhpXdbL5DQ4tmPVrI7eaIfdCB3d_MzQpbdD0Zdo-AvmpUbqs0JSpdB_R8nPE=@protonmail.com>
 <CAHUJnBBduZA9KgcYwEG7Zn3qPrBpnCRWukQpPzJJjpb3S933Ag@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 Mon, Mar 7, 2022 at 7:06 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> > But cross-input signature aggregation is a nice-to-have we want for Bit=
coin, and, to me, cross-input sigagg is not much different from cross-input=
 puzzle/solution compression.
>
> Cross-input signature aggregation has a lot of headaches unless you're us=
ing BLS signatures, in which case you always aggregate everything all the t=
ime because it can be done after the fact noninteractively. In that case it=
 makes sense to have a special aggregated signature which always comes with=
 a transaction or block. But it might be a bit much to bundle both lisp and=
 BLS support into one big glop.

You misunderstand my point.

I am not saying "we should add sigagg and lisp together!"

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.

> > For example you might have multiple HTLCs, with mostly the same code ex=
cept for details like who the acceptor and offerrer are, exact hash, and ti=
melock, and you could claim multiple HTLCs in a single tx and feed the deta=
ils 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 protoco=
ls use the same code for implementing HTLC.
>
> HTLCs, at least in Chia, have embarrassingly=C2=A0little code in them. Li=
ke, 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 count=
, 13 bytes.
If you have a bunch of HTLCs you want to claim, you can reduce your witness=
 data by 13 bytes minus whatever number of bytes you need to indicate this.
That amounts to about 3 vbytes per HTLC, which can be significant enough to=
 be worth it (consider that Taproot moving away from encoded signatures sav=
es only 9 weight units per signature, i.e. about 2 vbytes).

Do note that PTLCs remain more space-efficient though, so forget about HTLC=
s and just use PTLCs.

>
> > This does not apply to current Bitcoin since we no longer accept a SCRI=
PT 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 equivalent o=
f `OP_PUSH`es, while `scriptSig` can in theory contain non-`OP_PUSH` opcode=
s.
xref. `1 RETURN`.

As-is, with SegWit the spender no longer is able to provide any SCRIPT at a=
ll, but new opcodes may allow the spender to effectively inject any SCRIPT =
they want, once again, because `witness` data may now become code.

> 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 we=
ll.
And a bug is really "a weird surprise" --- xref TheDAO incident.

This makes me kinda wary of using such covenant features at all, and if stu=
ff 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 che=
ck that `SIGHASH_ANYPREVOUT`/`OP_CHECKTEMPLATEVERIFY` were implemented corr=
ectly.
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=
.
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 feat=
ure.

Regards,
ZmnSCPxj