> Are new jets consensus critical? > Do I need to debate `LOT` *again* if I want to propose a new jet?
New jets should never need a consensus change. A jet is just an optimization - a way to both save bytes in transmission as well as save processing power. Anything that a jet can do can be done with a normal script. Because of this, a script using a particular jet could be sent to a node that doesn't support that jet by simply expanding the jet into the script fragment it represents. The next node that recognizes the jet can remove the extraneous bytes so extra transmission and processing-time would only be needed for nodes that don't support that jet. (Note that this interpretation of a 'jet' is probably slightly different than as described for simplicity, but the idea is basically the same). 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. > 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. > 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. On Sat, Mar 5, 2022 at 5:02 PM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > 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
