Good morning Billy,
> > I think we would want to have a cleanstack rule at some point
>
> Ah is this a rule where a script shouldn't validate if more than just a true is left on the stack? I can see how that would prevent the non-soft-fork version of what I'm proposing.
Yes.
There was also an even stronger cleanstack rule where the stack and alt stack are totally empty.
This is because a SCRIPT really just returns "valid" or "invalid", and `OP_VERIFY` can be trivially appended to a SCRIPT that leaves a single stack item to convert to a SCRIPT that leaves no stack items and retains the same behavior.
>
> > How large is the critical mass needed?
>
> Well it seems we've agreed that were we going to do this, we would want to at least do a soft-fork to make known jet scripts lighter weight (and unknown jet scripts not-heavier) than their non-jet counterparts. So given a situation where this soft fork happens, and someone wants to implement a new jet, how much critical mass would be needed for the network to get some benefit from the jet? Well, the absolute minimum for some benefit to happen is that two nodes that support that jet are connected. In such a case, one node can send that jet scripted transaction along without sending the data of what the jet stands for. The jet itself is pretty small, like 2 or so bytes. So that does impose a small additional cost on nodes that don't support a jet. For 100,000 nodes, that means 200,000 bytes of transmission would need to be saved for a jet to break even. So if the jet stands for a 22 byte script, it would break even when 10% of the network supported it. If the jet stood for a 102 byte script, it would break even when 2% of the network supported it. So how much critical mass is necessary for it to be worth it depends on what the script is.
The math seems reasonable.
> The question I have is: where would the constants table come from? Would it reference the original positions of items on the witness stack?
The constants table would be part of the SCRIPT puzzle, and thus not in the witness solution.
I imagine the SCRIPT would be divided into two parts: (1) a table of constants and (2) the actual opcodes to execute.
Regards,
ZmnSCPxj