Thanks for the clarification. You don't think referring to the microcode via its hash, effectively using 32-byte encoding of opcodes, is still rather long winded?
On Tue, Mar 22, 2022 at 12:23 PM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > Good morning Russell, > > > Setting aside my thoughts that something like Simplicity would make a > better platform than Bitcoin Script (due to expression operating on a more > narrow interface than the entire stack (I'm looking at you OP_DEPTH)) there > is an issue with namespace management. > > > > If I understand correctly, your implication was that once opcodes are > redefined by an OP_RETURN transaction, subsequent transactions of that > opcode refer to the new microtransaction. But then we have a race > condition between people submitting transactions expecting the outputs to > refer to the old code and having their code redefined by the time they do > get confirmed (or worse having them reorged). > > No, use of specific microcodes is opt-in: you have to use a specific > `0xce` Tapscript version, ***and*** refer to the microcode you want to use > via the hash of the microcode. > > The only race condition is reorging out a newly-defined microcode. > This can be avoided by waiting for deep confirmation of a newly-defined > microcode before actually using it. > > But once the microcode introduction outpoint of a particular microcode has > been deeply confirmed, then your Tapscript can refer to the microcode, and > its meaning does not change. > > Fullnodes may need to maintain multiple microcodes, which is why creating > new microcodes is expensive; they not only require JIT compilation, they > also require that fullnodes keep an index that cannot have items deleted. > > > The advantage of the microcode scheme is that the size of the SCRIPT can > be used as a proxy for CPU load ---- just as it is done for current Bitcoin > SCRIPT. > As long as the number of `UOP_` micro-opcodes that an `OP_` code can > expand to is bounded, and we avoid looping constructs, then the CPU load is > also bounded and the size of the SCRIPT approximates the amount of > processing needed, thus microcode does not require a softfork to modify > weight calculations in the future. > > Regards, > ZmnSCPxj >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
