From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Billy Tetrud <billy.tetrud@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT
Date: Sun, 06 Mar 2022 20:38:17 +0000 [thread overview]
Message-ID: <-3inEV9Skl4K8wQefM7I0EbYzQc-zWV4QPgJSXKNxx0X_2EbwyTRmVjwooU1a8wFRNU41Cr41hb-Ajno_nV39U9rOge1oaUg9MvKmQ7-v30=@protonmail.com> (raw)
In-Reply-To: <CAGpPWDYCPgLxO4rDRVhK+ye50EBinKKXdiJTG+4CoW8SDtvJAA@mail.gmail.com>
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 way to how segwit separated the witness out.
The way we did this in SegWit was to *hide* the witness from unupgraded nodes, who are then unable to validate using the upgraded rules (because you are 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 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.
So if we make a script weigh less if it uses a jet, we have to do that by telling 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 unupgraded 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 code.
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 incentive for end-users to use a jet, as they would still pay the same price anyway.
Now you might say "okay even if no end-users use a jet, we could have fullnodes 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 opcode 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 is filled with almost-but-not-quite-jettable code (and again, note that expanded forms of jets are varying sizes), your node has to look up all those jets 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 too, so now you are helping my DDoS.
> > 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.
Certainly a neat idea.
Again, lookup table tho.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2022-03-06 20:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-27 16:34 ZmnSCPxj
2022-03-05 19:12 ` Billy Tetrud
2022-03-05 23:02 ` ZmnSCPxj
2022-03-06 15:49 ` Billy Tetrud
2022-03-06 20:38 ` ZmnSCPxj [this message]
2022-03-07 17:26 ` Billy Tetrud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='-3inEV9Skl4K8wQefM7I0EbYzQc-zWV4QPgJSXKNxx0X_2EbwyTRmVjwooU1a8wFRNU41Cr41hb-Ajno_nV39U9rOge1oaUg9MvKmQ7-v30=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox