Published on: 2022-03-07T17:26:13+00:00
In the context of implementing a jet-like system in Bitcoin, the author presents three possibilities: implementing jets without requiring all nodes to upgrade, implementing lighter weighting by using a soft fork to hide jets from unupgraded nodes, and implementing jet registration in a soft fork. Upgraded nodes would query connections for support of jets and send transactions verbatim with the jet included in the script to upgraded nodes that support it. For non-upgraded nodes, the jet opcode call would be replaced with some data that contains the original jet opcode to be swapped back in when the transaction data reaches an upgraded node.The discussion highlights the need for security when releasing a new jet, as users of a new jet have no security if nobody else has upgraded. To incentivize end-users to use a jet, scripts must weigh less when using a jet. Full nodes could recognize jettable code and insert them automatically on transport, but this may result in a large lookup table once there are many jets. The proposal is to allow anyone to add a new jet, requiring a consensus change to implement a mechanism that allows any jet to be registered in userspace.While implementing jets in Bitcoin can optimize scripts, save bytes in transmission, and reduce processing power, changes in costs may occur. Adding jets would require debate and review to be added to Bitcoin core or other Bitcoin software. Implementing more general opcodes is useful, but their boundaries should be well understood before being added. The most general opcodes that can be fully reasoned about and come to a consensus on should be implemented. However, the implementation of `OP_FOLD` is possible without increasing the attack surface.The article discusses the usefulness of op_fold in Bitcoin and how it can provide bandwidth savings by programming as compression. Jets cover the majority of use cases that op_fold would otherwise have. The suggestion is to provide more general operations and identify the most important needs to be implemented on the blockchain layer. The more general an opcode is, the harder it is to understand the boundaries, so implementing the most general opcodes that can be fully reasoned about and come to a consensus on is recommended. Op_fold can still be useful with the proposed restrictions without increasing the attack surface.The Bitcoin Taproot update proposes the implementation of an `OP_FOLD` opcode, providing a looping mechanism for processing elements in an input structure and accumulating results. Restrictions are in place to prevent potential Denial of Service attacks through SCRIPT. Alternative suggestions include adding a field to limit the number of opcodes processed, allowing for multiple loops and loops-in-loops. While `OP_FOLD` improves bandwidth consumption without significantly increasing CPU consumption, trade-offs must be made in the Bitcoin SCRIPT design between general opcodes and complex opcodes.Bitcoin SCRIPT is a programming language used to implement OP_EVICT and general operations. The addition of an `OP_FOLD` operation should be safe as long as further operations admitting partiality are not added. Restricting the use of `OP_FOLD` ensures that its processing does not exceed that of a script without it. The article also discusses the possibility of adding an annex field to Taproot to indicate the maximum number of opcodes to be processed, allowing for lifting restrictions on `OP_FOLD` and multiple loops. The choice between providing more general operations or operations that do more depends on optimizing for specific uses in Bitcoin SCRIPT design.
Updated on: 2023-08-02T05:45:08.383421+00:00