Let me organize my thoughts on this a little more clearly. There's a couple
possibilities I can think of for a jet-like system:
A. We could implement jets now without a consensus change, and
without requiring all nodes to upgrade to new relay rules. Probably. This
would give upgraded nodes
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
> 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
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
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
`OP_FOLD`: A Looping Construct For Bitcoin SCRIPT
=
(This writeup requires at least some programming background, which I
expect most readers of this list have.)
Recently, some rando was ranting on the list about this weird crap
called `OP_EVICT`, a
