Date: Sun, 06 Mar 2022 20:38:17 +0000
To: Billy Tetrud <billy.tetrud@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <-3inEV9Skl4K8wQefM7I0EbYzQc-zWV4QPgJSXKNxx0X_2EbwyTRmVjwooU1a8wFRNU41Cr41hb-Ajno_nV39U9rOge1oaUg9MvKmQ7-v30=@protonmail.com>
In-Reply-To: <CAGpPWDYCPgLxO4rDRVhK+ye50EBinKKXdiJTG+4CoW8SDtvJAA@mail.gmail.com>
References: <rcWu5FJZQGCdQeFZSUKV2AylHwmlTYPWAnxvN-FP8lER3qFBLIYLPVH4-r0js0k6_Xy_TwxA3jWXZC15jFbAafNb_vnr3a54ZMrgAeTz6vM=@protonmail.com>
 <CAGpPWDawAQShRU4OYcVnOE+qmHQv79ahwhMeyALF8iwjkZ_sOg@mail.gmail.com>
 <1zAD-_yaVAjRfYOQmNn_lh1cIQ9yxtR_TpLpHfl3A8TbtTpHEpduMloN72b-zI8U4HjrXRCHBBee16Ly89OAZJohfJuewWNCCHuacBN5TE8=@protonmail.com>
 <CAGpPWDYCPgLxO4rDRVhK+ye50EBinKKXdiJTG+4CoW8SDtvJAA@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,

> 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=C2=A0way to how seg=
wit separated=C2=A0the witness out.

The way we did this in SegWit was to *hide* the witness from unupgraded nod=
es, who are then unable to validate using the upgraded rules (because you a=
re hiding the data from them!), which is why I bring up:

> > If a new jet is released but nobody else has upgraded, how bad is my se=
curity 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 i=
s for some reason not easily CPFPable or RBFable), then security might be a=
ffected if the unjetted=C2=A0scripts costs substantially more to mine.=
=C2=A0

So if we make a script weigh less if it uses a jet, we have to do that by t=
elling unupgraded nodes "this script will always succeed and has weight 0",=
 just like `scriptPubKey`s with `<0> <P2WKH hash>` are, to pre-SegWit nodes=
, spendable with an empty `scriptSig`.
At least, that is how I always thought SegWit worked.

Otherwise, a jet would never allow SCRIPT weights to decrease, as unupgrade=
d nodes who do not recognize the jet will have to be fed the entire code of=
 the jet and would consider the weight to be the expanded, uncompressed cod=
e.
And weight is a consensus parameter, blocks are restricted to 4Mweight.

So if a jet would allow SCRIPT weights to decrease, upgraded nodes need to =
hide them from unupgraded nodes (else the weight calculations of unupgraded=
 nodes will hit consensus checks), then if everybody else has not upgraded,=
 a user of a new jet has no security.

Not even the `softfork` form of chialisp that AJ is proposing in the other =
thread would help --- unupgraded nodes will simply skip over validation of =
the `softfork` form.

If the script does not weigh less if it uses a jet, then there is no incent=
ive for end-users to use a jet, as they would still pay the same price anyw=
ay.

Now you might say "okay even if no end-users use a jet, we could have fulln=
odes recognize jettable code and insert them automatically on transport".
But the lookup table for that could potentially be large once we have a few=
 hundred jets (and I think Simplicity already *has* a few hundred jets, so =
additional common jets would just add to that?), jettable code could start =
at arbitrary offsets of the original SCRIPT, and jettable code would likely=
 have varying size, that makes for a difficult lookup table.
In particular that lookup table has to be robust against me feeding it some=
 section of code that is *almost* jettable but suddenly has a different opc=
ode at the last byte, *and* handle jettable code of varying sizes (because =
of course some jets are going to e more compressible than others).
Consider an attack where I feed you a SCRIPT that validates trivially but i=
s filled with almost-but-not-quite-jettable code (and again, note that expa=
nded forms of jets are varying sizes), your node has to look up all those j=
ets but then fails the last byte of the almost-but-not-quite-jettable code,=
 so it ends up not doing any jetting.
And since the SCRIPT validated your node feels obligated to propagate it to=
o, so now you are helping my DDoS.

> >=C2=A0 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 an=
yone to add a new jet. Then each node can have their own policy to determin=
e which jets of the ones registered it wants to keep an index of and use. O=
n 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 b=
e worth building an optimized function for.=C2=A0This would require a conse=
nsus change to implement this mechanism, but thereafter any jet could be re=
gistered in userspace.

Certainly a neat idea.
Again, lookup table tho.

Regards,
ZmnSCPxj