Author: ZmnSCPxj 2022-03-07 23:35:04
Published on: 2022-03-07T23:35:04+00:00
In a Bitcoin-dev mailing list, a discussion is going on regarding the implementation of jet-like system for Bitcoin. The author has provided three possibilities to implement jets in Bitcoin. Possibility A suggests implementing jets without consensus change and upgrading all nodes to new relay rules, which would save upgraded nodes' validation performance and many upgraded nodes' relay savings. Transactions would be weighted the same as those without the use of jets. Possibility B adds lighter weighting by using a soft fork to put the jets in a part of the blockchain hidden from unupgraded nodes. Possibility C includes the above two possibilities and adds the jet registration idea in a soft fork.The author explains in detail the process of how using jets could work. For upgraded nodes, the transaction is sent with the jet included in the script, which is then replaced during validation or when a miner includes it in a block. For non-upgraded nodes that don't support jets, the jet opcode call is replaced before sending the transaction. However, this mechanism would require the existence of "extra ignored data," which may not exist at present.The author also discusses the possibility of an attack where a SCRIPT contains almost-but-not-quite-jettable code and suggests a rolling checksum idea to identify strings of a specific length at arbitrary offsets. To make jets more useful, the author suggests redesigning the language so that `OP_PUSH` is not in the opcode stream but has a separate table of constants attached to the actual SCRIPT.Finally, the author discusses the general vs. specific tension in information-theoretic terms and suggests starting with a terse but restricted language and slowly loosening up its restrictions by adding new capabilities in soft forks.
Updated on: 2023-05-22T18:10:22.145364+00:00