path: root/08/24180652c0c1b78e1bfd60bf91395a3a704fed

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D225CC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Mar 2022 15:50:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id CFD60404B6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Mar 2022 15:50:19 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001,
 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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 Urwh_oWRBRtO
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Mar 2022 15:50:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com
 [IPv6:2a00:1450:4864:20::62e])
 by smtp4.osuosl.org (Postfix) with ESMTPS id ACA93404A5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Mar 2022 15:50:18 +0000 (UTC)
Received: by mail-ej1-x62e.google.com with SMTP id dr20so27068210ejc.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 06 Mar 2022 07:50:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=V2Tg3CfMgCYpDjkZj87zmoSDAHNAuufk07xUjP95Z44=;
 b=Ig1E9P9EgT7uQvZcrcqstVgkevVNAI838Iw8GAmNHby00rkrdRdK6wdbmOtyZCNvTI
 IUwmKfTSGVzOMj3SBp0T6V0rIZZ96U30q3oOfncdVZeVKGFEJ1hWAdJ3plDH3ht5XN5t
 em+/JATskog2uimx+G7GbO7QEN8mgWM6g0Sz6fw9XTZfRYEUtNnkGI3FX4bFwqW5ko1G
 illtDWwuGYYhoy3/21MTTihJFnuBwqeyzoVjxu+F6mwgpUIK8CootD0gnMbalyeMUc9v
 Kqkpc/cVB2XBPVHI2o9Cx2lShKhMHZaILW/dqPUUa4cxQFU5E75XsQtEE16rSZr9Lclb
 0nrQ==
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=V2Tg3CfMgCYpDjkZj87zmoSDAHNAuufk07xUjP95Z44=;
 b=jNjGGca+v5H48BQXBn/dZGGDuTvCh5GdAxaFIEzTczgysi2SHDFs1E/Jy61dlYLlSA
 /zqS3mveeCXCeGc92D5ReAmHOLOzL6VSa5mewNwIAwQq+3YgXiW4OLEaRSI3QIYKMJGp
 sJTpt/TEm8XN+vnUajJZDQq8MM9D+1IsSGRPq/r9sKxxjJ5G4BrxY3fYV1i/DAY4BieD
 p9GQZqo4Bk8fS2w9xKuxDSJO1teRWp6vv2W7H0ppY3zSDX6oBsfam5WGnxCVZ1KlMv+p
 6eOHE0ZuDbeZOrwdrVHBu4W95RvE+5reypVa5jvvGMRNhgkb/OFk9eaYwkgMGyyZIvz5
 5nFg==
X-Gm-Message-State: AOAM531iFpvR+1dDkFAp5FY/4bKdMI8KcmqdARJmlPMzAhiXBLFLcRml
 Vzu4sBPK31wcE0hyfHCwd7AufkNXZDDy+z6Z1X426qMe
X-Google-Smtp-Source: ABdhPJzgDqm7mow8B+xBRZUDKibXQBAGdsSFxE8mZLGKi5bs+MIF9rDGztylT/sNn77JtWLfrsOmNYmHZRF38GDwFJY=
X-Received: by 2002:a17:907:72c3:b0:6da:b4d1:415a with SMTP id
 du3-20020a17090772c300b006dab4d1415amr6015352ejc.709.1646581816451; Sun, 06
 Mar 2022 07:50:16 -0800 (PST)
MIME-Version: 1.0
References: <rcWu5FJZQGCdQeFZSUKV2AylHwmlTYPWAnxvN-FP8lER3qFBLIYLPVH4-r0js0k6_Xy_TwxA3jWXZC15jFbAafNb_vnr3a54ZMrgAeTz6vM=@protonmail.com>
 <CAGpPWDawAQShRU4OYcVnOE+qmHQv79ahwhMeyALF8iwjkZ_sOg@mail.gmail.com>
 <1zAD-_yaVAjRfYOQmNn_lh1cIQ9yxtR_TpLpHfl3A8TbtTpHEpduMloN72b-zI8U4HjrXRCHBBee16Ly89OAZJohfJuewWNCCHuacBN5TE8=@protonmail.com>
In-Reply-To: <1zAD-_yaVAjRfYOQmNn_lh1cIQ9yxtR_TpLpHfl3A8TbtTpHEpduMloN72b-zI8U4HjrXRCHBBee16Ly89OAZJohfJuewWNCCHuacBN5TE8=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 6 Mar 2022 09:49:56 -0600
Message-ID: <CAGpPWDYCPgLxO4rDRVhK+ye50EBinKKXdiJTG+4CoW8SDtvJAA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000043674a05d98eb450"
X-Mailman-Approved-At: Sun, 06 Mar 2022 20:08:11 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT
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: Sun, 06 Mar 2022 15:50:19 -0000

--00000000000043674a05d98eb450
Content-Type: text/plain; charset="UTF-8"

> Are new jets consensus critical?
> Do I need to debate `LOT` *again* if I want to propose a new jet?

New jets should never need a consensus change. A jet is just an
optimization - a way to both save bytes in transmission as well as save
processing power. Anything that a jet can do can be done with a normal
script. Because of this, a script using a particular jet could be sent to a
node that doesn't support that jet by simply expanding the jet into the
script fragment it represents. The next node that recognizes the jet can
remove the extraneous bytes so extra transmission and processing-time would
only be needed for nodes that don't support that jet. (Note that this
interpretation of a 'jet' is probably slightly different than as described
for simplicity, but the idea is basically the same). Even changing the
weight of a transaction using jets (ie making a script weigh less if it
uses a jet) could be done in a similar way to how segwit separated the
witness out.

> If a new jet is released but nobody else has upgraded, how bad is my
security if I use the new jet?

Security wouldn't be directly affected, only (potentially) cost. If your
security depends on cost (eg if it depends on pre-signed transactions and
is for some reason not easily CPFPable or RBFable), then security might be
affected if the unjetted scripts costs substantially more to mine.

>  I suppose the point would be --- how often *can* we add new jets?

A simple jet would be something that's just added to bitcoin software and
used by nodes that recognize it. This would of course require some debate
and review to add it to bitcoin core or whichever bitcoin software you want
to add it to. However, the idea I proposed in my last email would allow
anyone to add a new jet. Then each node can have their own policy to
determine which jets of the ones registered it wants to keep an index of
and use. On its own, it wouldn't give any processing power optimization,
but it would be able to do the same kind of script compression you're
talking about op_fold allowing. And a list of registered jets could inform
what jets would be worth building an optimized function for. This would
require a consensus change to implement this mechanism, but thereafter any
jet could be registered in userspace.

On Sat, Mar 5, 2022 at 5:02 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Billy,
>
> > It sounds like the primary benefit of op_fold is bandwidth savings.
> Programming as compression. But as you mentioned, any common script could
> be implemented as a Simplicity jet. In a world where Bitcoin implements
> jets, op_fold would really only be useful for scripts that can't use jets,
> which would basically be scripts that aren't very often used. But that
> inherently limits the usefulness of the opcode. So in practice, I think
> it's likely that jets cover the vast majority of use cases that op fold
> would otherwise have.
>
> I suppose the point would be --- how often *can* we add new jets?
> Are new jets consensus critical?
> If a new jet is released but nobody else has upgraded, how bad is my
> security if I use the new jet?
> Do I need to debate `LOT` *again* if I want to propose a new jet?
>
> > A potential benefit of op fold is that people could implement smaller
> scripts without buy-in from a relay level change in Bitcoin. However, even
> this could be done with jets. For example, you could implement a consensus
> change to add a transaction type that declares a new script fragment to
> keep a count of, and if the script fragment is used enough within a
> timeframe (eg 10000 blocks) then it can thereafter be referenced by an id
> like a jet could be. I'm sure someone's thought about this kind of thing
> before, but such a thing would really relegate the compression abilities of
> op fold to just the most uncommon of scripts.
> >
> > > * We should provide more *general* operations. Users should then
> combine those operations to their specific needs.
> > > * We should provide operations that *do more*. Users should identify
> their most important needs so we can implement them on the blockchain layer.
> >
> > That's a useful way to frame this kind of problem. I think the answer
> is, as it often is, somewhere in between. Generalization future-proofs your
> system. But at the same time, the boundary conditions of that generalized
> functionality should still be very well understood before being added to
> Bitcoin. The more general, the harder to understand the boundaries. So imo
> we should be implementing the most general opcodes that we are able to
> reason fully about and come to a consensus on. Following that last
> constraint might lead to not choosing very general opcodes.
>
> Yes, that latter part is what I am trying to target with `OP_FOLD`.
> As I point out, given the restrictions I am proposing, `OP_FOLD` (and any
> bounded loop construct with similar restrictions) is implementable in
> current Bitcoin SCRIPT, so it is not an increase in attack surface.
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr"><div>&gt; Are new jets consensus critical?</div><div>&gt; =
Do I need to debate `LOT` *again* if I want to propose a new jet?</div><div=
><br></div><div>New jets should never need=C2=A0a consensus change. A jet i=
s just an optimization - a way to both save bytes in transmission as well a=
s save processing power. Anything that a jet can do can be done with a norm=
al script. Because of this, a script using a particular jet could be sent t=
o a node that doesn&#39;t support that jet by simply expanding the jet into=
 the script fragment it represents. The next node that recognizes the jet c=
an remove the extraneous bytes so extra transmission and processing-time wo=
uld only be needed for nodes that don&#39;t support that jet. (Note that th=
is interpretation of a &#39;jet&#39; is probably slightly different than as=
 described for simplicity, but the idea is basically the same). Even changi=
ng the weight of a transaction using jets (ie making a script weigh less if=
 it uses a jet) could be done in a similar=C2=A0way to how segwit separated=
=C2=A0the witness out.<br></div><div><br></div><div>&gt; If a new jet is re=
leased but nobody else has upgraded, how bad is my security if I use the ne=
w jet?</div><div><br></div><div>Security wouldn&#39;t be directly affected,=
 only (potentially) cost. If your security depends on cost (eg if it depend=
s on pre-signed transactions and is for some reason not easily CPFPable or =
RBFable), then security might be affected if the unjetted=C2=A0scripts cost=
s substantially more to mine.=C2=A0</div><div><br></div>&gt;=C2=A0

I suppose the point would be --- how often *can* we add new jets?<div><br><=
/div><div>A simple jet would be something that&#39;s just added to bitcoin =
software and used by nodes that recognize it. This would of course require =
some debate and review to add it to bitcoin core or whichever bitcoin softw=
are you want to add it to. However, the idea I proposed in my last email wo=
uld allow anyone to add a new jet. Then each node can have their own policy=
 to determine which jets of the ones registered it wants to keep an index o=
f and use. On its own, it wouldn&#39;t give any processing power optimizati=
on, but it would be able to do the same kind of script compression you&#39;=
re talking about op_fold allowing. And a list of registered jets could info=
rm what jets would be worth building an optimized function for.=C2=A0This w=
ould require a consensus change to implement this mechanism, but thereafter=
 any jet could be registered in userspace.</div></div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Mar 5, 2022 at 5:02=
 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blan=
k">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">Good morning Billy,<br>
<br>
&gt; It sounds like the primary benefit of op_fold is bandwidth savings. Pr=
ogramming as compression. But as you mentioned, any common script could be =
implemented as a Simplicity jet. In a world where Bitcoin implements jets, =
op_fold would really only be useful for scripts that can&#39;t use jets, wh=
ich would basically be scripts that aren&#39;t very often used. But that in=
herently limits the usefulness of the opcode. So in practice, I think it&#3=
9;s likely that jets cover the vast majority of use cases that op fold woul=
d otherwise have.<br>
<br>
I suppose the point would be --- how often *can* we add new jets?<br>
Are new jets consensus critical?<br>
If a new jet is released but nobody else has upgraded, how bad is my securi=
ty if I use the new jet?<br>
Do I need to debate `LOT` *again* if I want to propose a new jet?<br>
<br>
&gt; A potential benefit of op fold is that people could implement smaller =
scripts without buy-in from a relay level change in Bitcoin. However, even =
this could be done with jets. For example, you could implement a consensus =
change to add a transaction type that declares a new script fragment to kee=
p a count of, and if the script fragment is used enough within a timeframe =
(eg 10000 blocks) then it can thereafter be referenced by an id like a jet =
could be. I&#39;m sure someone&#39;s thought about this kind of thing befor=
e, but such a thing would really relegate the compression abilities of op f=
old to just the most uncommon of scripts.=C2=A0<br>
&gt;<br>
&gt; &gt; *=C2=A0We should provide more *general* operations.=C2=A0Users sh=
ould then combine those operations to their=C2=A0specific needs.<br>
&gt; &gt; * We should provide operations that *do more*.=C2=A0Users should =
identify their most important needs so=C2=A0we can implement them on the bl=
ockchain layer.<br>
&gt;<br>
&gt; That&#39;s a useful way to frame this kind of problem. I think the ans=
wer is, as it often is, somewhere in between. Generalization future-proofs =
your system. But at the same time, the boundary conditions of that generali=
zed functionality should still be very well understood before being added t=
o Bitcoin. The more general, the harder to understand the boundaries. So im=
o we should be implementing the most general opcodes that we are able to re=
ason fully about and come to a consensus on. Following that last constraint=
 might lead to not choosing very general opcodes.<br>
<br>
Yes, that latter part is what I am trying to target with `OP_FOLD`.<br>
As I point out, given the restrictions I am proposing, `OP_FOLD` (and any b=
ounded loop construct with similar restrictions) is implementable in curren=
t Bitcoin SCRIPT, so it is not an increase in attack surface.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--00000000000043674a05d98eb450--