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"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT
Precedence: list

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