path: root/18/d660581da64604d8338319e04e06b1812feae1

Return-Path: <bram@chia.net>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 95D8BC0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Mar 2022 06:41:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 7053860EEB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Mar 2022 06:41:09 +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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=chia.net
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id tVKYW4_fi7aK
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Mar 2022 06:41:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com
 [IPv6:2a00:1450:4864:20::134])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 5C17D60E05
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 16 Mar 2022 06:41:04 +0000 (UTC)
Received: by mail-lf1-x134.google.com with SMTP id bu29so2230170lfb.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 15 Mar 2022 23:41:04 -0700 (PDT)
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=4+/rZ6pEXminpRfOYDoi6dwPX0GeSXh3Fuj6r2COOPQ=;
 b=SjsFwrgA+ojZRq6nZeEJbfzioUswQzIsL0w4SkQM25UXzVseAlSe5O+8F6HXZ9ybS1
 T64Ll+ecxqdtKoFhzFU1Av4ifxvQDs7uDeOQ2zxRe4A6LKuDleyCprKjNzPg5h1buzLm
 h+FAjE2/wBpD/nSuh3IcMBHYsyYO6nsfuMfTNDY7TgfR7uWU7AKffiL5cQblXbJDHndr
 /a0de/PxNawepcabbj/iqgjLDORqJu4pzXCz45Rxp6Yq3hUddLT5IHcAOTltX6Z2ePZT
 h53z01Cg97N81VDKYRfwdJUpsPa1FAziHIRKqhZDBYvXnjeEzaHhD6z9PFnIHh0uO8Gc
 Ag2Q==
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=4+/rZ6pEXminpRfOYDoi6dwPX0GeSXh3Fuj6r2COOPQ=;
 b=8IQhAhoSk6owiljObjyWsmDs7qnasT5SaXr6qOiDPmaA6lPKtyj4kZk+tzgqauZlct
 UOF3Ub5NQnfyOdz1+6JLXyN+tPN6RzQpDZ5v13yBq6XMEEUsNcbK/QC51bRHPBZQSwzC
 8fGIsDbInNaVBKZ9FtD+PLQ5SIqKZJtah3Q64yjPyjxmQ7k/DhXxoyHexkLkYAPtlPRT
 5iG/fJvG1SJXVz5RCfjvrjp00TbqQKuPxsZRoRDZ79tPoHMXVK2MKARsFkSa9KrkdzhH
 cv+fw5aNWFZigeDT5drdl/AL4oTj5t89VwG9JxF5uaAzFtizG0c3y6k/qCiTP0IJh1C2
 RA1A==
X-Gm-Message-State: AOAM530LG2t8+PA1sciwOlIWX14vHlOfnZfIyzERgpue/BWT41QBn0fv
 VjxBCGxcVhUEdwYmFBmWtdvhDUTs/lYMxlyeLeiqvg==
X-Google-Smtp-Source: ABdhPJyEQFExEQcJ7rn2592luZPhOVol6x17ZpGosa66Re4+U2KhdAS6IoSPrBe9hQZYi9gCn9oZg9ng2rIk1LJLjVU=
X-Received: by 2002:a05:6512:39d3:b0:448:4660:5f99 with SMTP id
 k19-20020a05651239d300b0044846605f99mr18355505lfu.180.1647412862076; Tue, 15
 Mar 2022 23:41:02 -0700 (PDT)
MIME-Version: 1.0
References: <20220308012719.GA6992@erisian.com.au>
 <NYPPZ7B4S9BQluVvyYLm7iBlBqmni5jOUYTqLtyZjCcSblwHhpXdbL5DQ4tmPVrI7eaIfdCB3d_MzQpbdD0Zdo-AvmpUbqs0JSpdB_R8nPE=@protonmail.com>
 <CAHUJnBBduZA9KgcYwEG7Zn3qPrBpnCRWukQpPzJJjpb3S933Ag@mail.gmail.com>
 <lMd2d3ntj6T-VfDDZ0SHn7cUdWWeFFWO3sHolPwMTdRyGUMRY8JwtICT0vbNy9PPg-u_inUplQ-OvB-wKvXNkEUB17pXBhA7ZDwu9vxiRx0=@protonmail.com>
In-Reply-To: <lMd2d3ntj6T-VfDDZ0SHn7cUdWWeFFWO3sHolPwMTdRyGUMRY8JwtICT0vbNy9PPg-u_inUplQ-OvB-wKvXNkEUB17pXBhA7ZDwu9vxiRx0=@protonmail.com>
From: Bram Cohen <bram@chia.net>
Date: Tue, 15 Mar 2022 23:40:51 -0700
Message-ID: <CAHUJnBDMGmay0TYwzV87AaVQuGWoVG0s5vf+K6PikGN7sesxJQ@mail.gmail.com>
To: ZmnSCPxj <zmnscpxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000071636805da50325c"
X-Mailman-Approved-At: Wed, 16 Mar 2022 16:04:24 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
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: Wed, 16 Mar 2022 06:41:09 -0000

--00000000000071636805da50325c
Content-Type: text/plain; charset="UTF-8"

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
incentivizes key reuse which isn't such a great thing.


>
> > > 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
> 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
> protocols use the same code for implementing HTLC.
> >
> > HTLCs, at least in Chia, have embarrassingly little 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
> 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
> saves only 9 weight units per signature, i.e. about 2 vbytes).
>

Oh I see. That's already extremely small overhead. When you start
optimizing 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.


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


> > > 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 equivalent
> of `OP_PUSH`es, while `scriptSig` can in theory contain non-`OP_PUSH`
> opcodes.
> 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
adherence to no side effects.


> 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 graftroot
is implemented in CLVM. The benefit of this approach is that new
functionality can be implemented and deployed immediately rather than
having to painstakingly go through a soft fork deployment for each thing.

--00000000000071636805da50325c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, Mar 9, 2022 at 6:30 AM ZmnSCPxj &=
lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&g=
t; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">I am pointing out that:<br>
<br>
* We want to save bytes by having multiple inputs of a transaction use the =
same single signature (i.e. sigagg).<br>
<br>
is not much different from:<br>
<br>
* We want to save bytes by having multiple inputs of a transaction use the =
same `scriptPubKey` template.<br></blockquote><div><br></div><div>Fair poin=
t. In the past Bitcoin has been resistant to such things because for exampl=
e reusing pubkeys can save you from having to separately pay for the reveal=
s of all of them but letting people get credit for that incentivizes key re=
use which isn&#39;t such a great thing.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">
<br>
&gt; &gt; For example you might have multiple HTLCs, with mostly the same c=
ode except for details like who the acceptor and offerrer are, exact hash, =
and timelock, and you could claim multiple HTLCs in a single tx and feed th=
e details separately but the code for the HTLC is common to all of the HTLC=
s.<br>
&gt; &gt; You do not even need to come from the same protocol if multiple p=
rotocols use the same code for implementing HTLC.<br>
&gt;<br>
&gt; HTLCs, at least in Chia, have embarrassingly=C2=A0little code in them.=
 Like, so little that there&#39;s almost nothing to compress.<br>
<br>
In Bitcoin at least an HTLC has, if you remove the `OP_PUSH`es, by my count=
, 13 bytes.<br>
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.=
<br>
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).<br></blockquote=
><div><br></div><div>Oh I see. That&#39;s already extremely small overhead.=
 When you start optimizing at that level you wind up doing things like pull=
ing all the HTLCs into the same block to take the overhead of pulling in th=
e template only once.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
<br>
Do note that PTLCs remain more space-efficient though, so forget about HTLC=
s and just use PTLCs.<br></blockquote><div><br></div><div>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 scratch.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; &gt; This d=
oes not apply to current Bitcoin since we no longer accept a SCRIPT from th=
e spender, we now have a witness stack.<br>
&gt;<br>
&gt; 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.<br>
<br>
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.<br>
xref. `1 RETURN`.<br></blockquote><div><br></div><div>It&#39;s very normal =
when you&#39;re using lisp for snippets of code to be passed in as data and=
 then verified and executed. That&#39;s enabled by the extreme adherence to=
 no side effects.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">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 sad=
dened, as I now have to contend with the complexity of covenant features an=
d carefully check that `SIGHASH_ANYPREVOUT`/`OP_CHECKTEMPLATEVERIFY` were i=
mplemented correctly.<br></blockquote><div><br></div><div>Even the &#39;sta=
ndard format&#39; transaction which supports taproot and graftroot is imple=
mented in CLVM. The benefit of this approach is that new functionality can =
be implemented and deployed immediately rather than having to painstakingly=
 go through a soft fork deployment for each thing.</div><div><br></div></di=
v></div>

--00000000000071636805da50325c--