path: root/7a/6770661295304fc5cb0968ca28a0f5e565dbe5

Return-Path: <bram@chia.net>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E1814C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 03:08:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id CF88060BEA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 03:08:07 +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 HO1HrP3tsN4X
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 03:08:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [IPv6:2a00:1450:4864:20::232])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 083D460BE0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Mar 2022 03:08:03 +0000 (UTC)
Received: by mail-lj1-x232.google.com with SMTP id o6so1237284ljp.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 08 Mar 2022 19:08:03 -0800 (PST)
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=jof4IUJCbb4SQ8nc1fu0D+Qodn5ZGoSTZJ3RnXEw5To=;
 b=r1Oa9/uFJ3Gi1OJO+uspUAf8Xsn+UETn1tcYK6rnR1/UF4rJkKxMyp9VjxUOWAnr3e
 SyKk1HRQr7tJ3zHhPSDLbUjr7IZ+3h00sfIs4F253555N5shrNc7ptu5M56SBsXbAGsW
 Eoi3U6USke8ZkC0XUXkuvA/k8AgaqniEFyH6MWJRxMUYnvCGk9HmY4whyzbMKJOC5h3R
 HVoIEIyegRnaEBS6UEfAh7qzxmPcwOK3DT4GUtISDWffOEDBUk+OUtjiSAVp3o8oWkRp
 O+UP87Vb5zHsopEIYE6Mab6ss7ljYquxCsCjpkYwzV1hr8KhboC4g+GhcT84C4rhutbH
 RTQQ==
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=jof4IUJCbb4SQ8nc1fu0D+Qodn5ZGoSTZJ3RnXEw5To=;
 b=zvEsW9Ngdt+K47N3eursB7x6Xt4ozpDVtsSoohg9rHql9IZ//jMuqFhVvamt9qn8wb
 aL1a+a8+e1/IbgoHdiIY1RyVEWHE4hiKjQDJ7CIGltGE4O4v/y2MSdFjVvgp71FGzTbl
 EkFa+iHDgOPqmYYcpsevrAiF4TexoXHX+MVfjAhPG/wz/z1Lu+q4PxOFtDEm/lIXx3yr
 wlP6Lk9X3hyiFVkesag14WKuK5qiuDa5z/yiUMdRIDiBcIHGltGVvpYAol3nznZ+Le0V
 b9ENpR135Pq+RVRhJjqYWtvHwSh1HyERbNehoTvjcAUTR35QvvHfqVJfrsfZbWklIeAu
 /PEA==
X-Gm-Message-State: AOAM531223exqejIN9N4r8sC/k5e1ZgWfwlMmRtwe57QCHvvbqcbjT9+
 N45dNKpMbRd+bge1VQ0uvrzEZclrur1bvxVr9kydbQ==
X-Google-Smtp-Source: ABdhPJyB585E66Cnz5FxK9aVUAUOnC68CM+cXjJBtfVGEQWTS5w+Jn1wQgrypJ0+7Dg0OiKQhTQm89u5+547LPj3CGw=
X-Received: by 2002:a2e:924d:0:b0:246:370c:5618 with SMTP id
 v13-20020a2e924d000000b00246370c5618mr12487576ljg.358.1646795281974; Tue, 08
 Mar 2022 19:08:01 -0800 (PST)
MIME-Version: 1.0
References: <20220308012719.GA6992@erisian.com.au>
 <NYPPZ7B4S9BQluVvyYLm7iBlBqmni5jOUYTqLtyZjCcSblwHhpXdbL5DQ4tmPVrI7eaIfdCB3d_MzQpbdD0Zdo-AvmpUbqs0JSpdB_R8nPE=@protonmail.com>
In-Reply-To: <NYPPZ7B4S9BQluVvyYLm7iBlBqmni5jOUYTqLtyZjCcSblwHhpXdbL5DQ4tmPVrI7eaIfdCB3d_MzQpbdD0Zdo-AvmpUbqs0JSpdB_R8nPE=@protonmail.com>
From: Bram Cohen <bram@chia.net>
Date: Tue, 8 Mar 2022 19:07:51 -0800
Message-ID: <CAHUJnBBduZA9KgcYwEG7Zn3qPrBpnCRWukQpPzJJjpb3S933Ag@mail.gmail.com>
To: ZmnSCPxj <zmnscpxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000ccd98e05d9c06733"
X-Mailman-Approved-At: Wed, 09 Mar 2022 13:10:51 +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, 09 Mar 2022 03:08:08 -0000

--000000000000ccd98e05d9c06733
Content-Type: text/plain; charset="UTF-8"

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
> Bitcoin, 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
using BLS signatures, in which case you always aggregate everything all the
time 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.



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


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


> So this seems to be more like "do not write broken SCRIPTs"?
>

In general if people footgun that's their own fault. The resistance to
covenants and capabilities in the past has largely been around what would
happen if you had opt-out covenants which acted as riders and could monkey
around in later spends which were none of their business. But if they're
fully baked into the scriptpubkey then they're opted into by the recipient
and there aren't any weird surprises.

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

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Mar 7, 2022 at 7:06 PM 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"><br>
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.<br></blockquote><div><br></div><div>Cross-input s=
ignature aggregation has a lot of headaches unless you&#39;re using BLS sig=
natures, in which case you always aggregate everything all the time because=
 it can be done after the fact noninteractively. In that case it makes sens=
e to have a special aggregated signature which always comes with a transact=
ion or block. But it might be a bit much to bundle both lisp and BLS suppor=
t into one big glop.</div><div><br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<br>
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.<br>
You do not even need to come from the same protocol if multiple protocols u=
se the same code for implementing HTLC.<br></blockquote><div><br></div><div=
>HTLCs, at least in Chia, have embarrassingly=C2=A0little code in them. Lik=
e, so little that there&#39;s almost nothing to compress.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">This does not apply =
to current Bitcoin since we no longer accept a SCRIPT from the spender, we =
now have a witness stack.<br></blockquote><div><br></div><div>My mental mod=
el of Bitcoin is to pretend that segwit was always there and the separation=
 of different sections of data is a semantic quibble.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">So this seems to be more=
 like &quot;do not write broken SCRIPTs&quot;?<br></blockquote><div><br></d=
iv><div>In general if people footgun that&#39;s their own fault. The resist=
ance to covenants and capabilities in the past has largely been around what=
 would happen if you had opt-out covenants which acted as riders and could =
monkey around in later spends which were none of their business. But if the=
y&#39;re fully baked into the scriptpubkey then they&#39;re opted into by t=
he recipient and there aren&#39;t any weird surprises.</div><div>=C2=A0</di=
v></div></div>

--000000000000ccd98e05d9c06733--