MIME-Version: 1.0
References: <EIwjydT0d68Z7Jv8_JlrCbQW6NHSSnIU5sWwE8eX2rm9K3djfzU3nQqUrmt44U8-L9sObegelHCV6Sk7h2nwq_HS1d26FophzjNU7xC_6SE=@protonmail.com>
 <CAGpPWDafWGcZJOUs4wSEt0DzFP8OXB4nrbx+9sUtTe5JfdwE_w@mail.gmail.com>
 <8R8D_XAaz7xYHmgWXR-pc3_GVFRzBCNdRT6s3PdKblrnnZPirB0orzLpEUvynBZHNBTiqOM_EteDdUjdqXQ5ZmrGbdlgnnfjIihgFZIXpUM=@protonmail.com>
 <CAGpPWDZwYE__YifZ0h7Bkftas6zN6Q7yOhB4rUAAwT0dcgYk7w@mail.gmail.com>
 <S_vdV5XIthqwwp_9BxZH3ofQGNR7zJbUe7CZtNrRBni0qNzGqwr9sprOT9UoQSy0Ouepr7Hxwck-DsMilyjVHnPYN7YE2NzHrS4mD8p5W9c=@protonmail.com>
In-Reply-To: <S_vdV5XIthqwwp_9BxZH3ofQGNR7zJbUe7CZtNrRBni0qNzGqwr9sprOT9UoQSy0Ouepr7Hxwck-DsMilyjVHnPYN7YE2NzHrS4mD8p5W9c=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 16 Mar 2022 10:59:00 -0500
Message-ID: <CAGpPWDapC1KfD9m=peHCsmD0evnhiREfE667xYXeo0KFwBKuDw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000eaaba805da57fe38"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Jets (Was: `OP_FOLD`: A Looping Construct For
	Bitcoin SCRIPT)
Precedence: list

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

>  The constants table would be part of the SCRIPT puzzle

Ah I see what you're saying now. You're not talking about referencing
inputs from the spender, but rather constants for the script writer to
parameterize a jet with. TBH I think both would be useful, and both could
potentially be done in the same way (ie reference their position in the
script before any evaluation starts). I think your idea is a good one.

Cheers

On Wed, Mar 16, 2022 at 10:39 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Billy,
>
> > > I think we would want to have a cleanstack rule at some point
> >
> > Ah is this a rule where a script shouldn't validate if more than just a
> true is left on the stack? I can see how that would prevent the
> non-soft-fork version of what I'm proposing.
>
> Yes.
> There was also an even stronger cleanstack rule where the stack and alt
> stack are totally empty.
> This is because a SCRIPT really just returns "valid" or "invalid", and
> `OP_VERIFY` can be trivially appended to a SCRIPT that leaves a single
> stack item to convert to a SCRIPT that leaves no stack items and retains
> the same behavior.
>
> >
> > > How large is the critical mass needed?
> >
> > Well it seems we've agreed that were we going to do this, we would want
> to at least do a soft-fork to make known jet scripts lighter weight (and
> unknown jet scripts not-heavier) than their non-jet counterparts. So given
> a situation where this soft fork happens, and someone wants to implement a
> new jet, how much critical mass would be needed for the network to get some
> benefit from the jet? Well, the absolute minimum for some benefit to happen
> is that two nodes that support that jet are connected. In such a case, one
> node can send that jet scripted transaction along without sending the data
> of what the jet stands for. The jet itself is pretty small, like 2 or so
> bytes. So that does impose a small additional cost on nodes that don't
> support a jet. For 100,000 nodes, that means 200,000 bytes of transmission
> would need to be saved for a jet to break even. So if the jet stands for a
> 22 byte script, it would break even when 10% of the network supported it.
> If the jet stood for a 102 byte script, it would break even when 2% of the
> network supported it. So how much critical mass is necessary for it to be
> worth it depends on what the script is.
>
> The math seems reasonable.
>
>
> > The question I have is: where would the constants table come from? Would
> it reference the original positions of items on the witness stack?
>
> The constants table would be part of the SCRIPT puzzle, and thus not in
> the witness solution.
> I imagine the SCRIPT would be divided into two parts: (1) a table of
> constants and (2) the actual opcodes to execute.
>
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr">&gt;=C2=A0

The constants table would be part of the SCRIPT puzzle<div><br></div><div>A=
h I see what you&#39;re saying now. You&#39;re not talking about referencin=
g inputs from the spender, but rather constants for the script writer to pa=
rameterize a jet with. TBH I think both would be useful, and both could pot=
entially be done in the same way (ie reference=C2=A0their position in the s=
cript before any evaluation starts). I think your idea is a good one.=C2=A0=
</div><div><br></div><div>Cheers</div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 16, 2022 at 10:39 AM ZmnS=
CPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com=
</a>&gt; wrote:<br></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">=
Good morning Billy,<br>
<br>
&gt; &gt; I think we would want to have a cleanstack rule at some point<br>
&gt;<br>
&gt; Ah is this a rule where a script shouldn&#39;t validate if more than j=
ust a true is left on the stack? I can see how that would prevent the non-s=
oft-fork version of what I&#39;m proposing.=C2=A0<br>
<br>
Yes.<br>
There was also an even stronger cleanstack rule where the stack and alt sta=
ck are totally empty.<br>
This is because a SCRIPT really just returns &quot;valid&quot; or &quot;inv=
alid&quot;, and `OP_VERIFY` can be trivially appended to a SCRIPT that leav=
es a single stack item to convert to a SCRIPT that leaves no stack items an=
d retains the same behavior.<br>
<br>
&gt;<br>
&gt; &gt; How large is the critical mass needed?<br>
&gt;<br>
&gt; Well it seems we&#39;ve agreed that were we going to do this, we would=
 want to at least do a soft-fork to make known jet scripts lighter weight (=
and unknown jet scripts not-heavier) than their=C2=A0non-jet counterparts. =
So given a situation where this soft fork happens, and someone wants to imp=
lement a new jet, how much critical mass would be needed for the network to=
 get some benefit from the jet? Well, the absolute minimum for some benefit=
 to happen is that two nodes that support that jet are connected. In such a=
 case, one node can send that jet scripted transaction along without sendin=
g the data of what the jet stands for. The jet itself is pretty small, like=
 2 or so bytes. So that does impose a small additional cost on nodes that d=
on&#39;t support a jet. For 100,000 nodes, that means 200,000 bytes of tran=
smission would need to be saved for a jet to break even. So if the jet stan=
ds for a 22 byte script, it would break even when 10% of the network suppor=
ted it. If the jet stood for a 102 byte script, it would break even when 2%=
 of the network supported it. So how much critical mass is necessary for it=
 to be worth it depends on what the script is.=C2=A0<br>
<br>
The math seems reasonable.<br>
<br>
<br>
&gt; The question I have is: where would the constants table come from? Wou=
ld it reference the original positions of items on the witness stack?=C2=A0=
<br>
<br>
The constants table would be part of the SCRIPT puzzle, and thus not in the=
 witness solution.<br>
I imagine the SCRIPT would be divided into two parts: (1) a table of consta=
nts and (2) the actual opcodes to execute.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000eaaba805da57fe38--