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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
