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: Sat, 05 Mar 2022 23:02:41 +0000 [thread overview]
Message-ID: <1zAD-_yaVAjRfYOQmNn_lh1cIQ9yxtR_TpLpHfl3A8TbtTpHEpduMloN72b-zI8U4HjrXRCHBBee16Ly89OAZJohfJuewWNCCHuacBN5TE8=@protonmail.com> (raw)
In-Reply-To: <CAGpPWDawAQShRU4OYcVnOE+qmHQv79ahwhMeyALF8iwjkZ_sOg@mail.gmail.com>
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
next prev parent reply other threads:[~2022-03-05 23:02 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 [this message]
2022-03-06 15:49 ` Billy Tetrud
2022-03-06 20:38 ` ZmnSCPxj
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='1zAD-_yaVAjRfYOQmNn_lh1cIQ9yxtR_TpLpHfl3A8TbtTpHEpduMloN72b-zI8U4HjrXRCHBBee16Ly89OAZJohfJuewWNCCHuacBN5TE8=@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