> The constants table would be part of the SCRIPT puzzle Ah I see what you're saying now. You're not talking about referencing inputs from the spender, but rather constants for the script writer to parameterize a jet with. TBH I think both would be useful, and both could potentially be done in the same way (ie reference their position in the script before any evaluation starts). I think your idea is a good one.
Cheers On Wed, Mar 16, 2022 at 10:39 AM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > 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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
