ZmnSCPxj [ARCHIVE] on Nostr: đź“… Original date posted:2022-03-05 đź“ť Original message:Good morning Billy, > It ...
đź“… Original date posted:2022-03-05
đź“ť Original message: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
đź“ť Original message: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