Date: Sat, 05 Mar 2022 23:02:41 +0000
To: Billy Tetrud <billy.tetrud@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <1zAD-_yaVAjRfYOQmNn_lh1cIQ9yxtR_TpLpHfl3A8TbtTpHEpduMloN72b-zI8U4HjrXRCHBBee16Ly89OAZJohfJuewWNCCHuacBN5TE8=@protonmail.com>
In-Reply-To: <CAGpPWDawAQShRU4OYcVnOE+qmHQv79ahwhMeyALF8iwjkZ_sOg@mail.gmail.com>
References: <rcWu5FJZQGCdQeFZSUKV2AylHwmlTYPWAnxvN-FP8lER3qFBLIYLPVH4-r0js0k6_Xy_TwxA3jWXZC15jFbAafNb_vnr3a54ZMrgAeTz6vM=@protonmail.com>
 <CAGpPWDawAQShRU4OYcVnOE+qmHQv79ahwhMeyALF8iwjkZ_sOg@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>
Subject: Re: [bitcoin-dev] `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT
Precedence: list

Good morning Billy,

> It sounds like the primary benefit of op_fold is bandwidth savings. Progr=
amming as compression. But as you mentioned, any common script could be imp=
lemented 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 wou=
ld basically be scripts that aren't very often used. But that inherently li=
mits 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 hav=
e.

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 securi=
ty 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 scr=
ipts without buy-in from a relay level change in Bitcoin. However, even thi=
s could be done with jets. For example, you could implement a consensus cha=
nge 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 cou=
ld 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.=C2=A0
>
> > *=C2=A0We should provide more *general* operations.=C2=A0Users should t=
hen combine those operations to their=C2=A0specific needs.
> > * We should provide operations that *do more*.=C2=A0Users should identi=
fy their most important needs so=C2=A0we can implement them on the blockcha=
in 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 sy=
stem. But at the same time, the boundary conditions of that generalized fun=
ctionality should still be very well understood before being added to Bitco=
in. The more general, the harder to understand the boundaries. So imo we sh=
ould be implementing the most general opcodes that we are able to reason fu=
lly 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 b=
ounded loop construct with similar restrictions) is implementable in curren=
t Bitcoin SCRIPT, so it is not an increase in attack surface.

Regards,
ZmnSCPxj