Author: Russell O'Connor 2019-05-23 22:06:45
Published on: 2019-05-23T22:06:45+00:00
The discussion revolves around the addition of OP_CHECKSIGFROMSTACK and whether it should be added for its direct purposes of enabling oracle verification and discreet log contracts. It is agreed that adding this operation doesn't preclude adding shortcuts such as SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTSHASHVERIFY, which should be supported directly, especially if they see widespread use in practice. The decision to deploy OP_CHECKSIGFROMSTACK will influence the design of these other proposals. For example, if it's deployed, then the design of OP_CHECKOUTPUTSHASHVERIFY ought to be simplified to OP_PUSHOUTPUTHASH and OP_PUSHNUMINPUTS (etc.) since the proposal would no longer be extending the expressiveness of Bitcoin Script. Furthermore, the post discusses the consequences of using OP_CHECKSIGFROMSTACK within taproot, where most of the "scary" recursive convents are not available without further extensions. It notes that since OP_CHECKSIGFROMSTACK doesn't directly address whether SIGHASH_ANYPREVOUT should be with or without a chaperone, it might get an opportunity to learn if users are willing to take advantage of the chaperone or bypass it by using a short well-known pubkey.There is a debate about whether to add OP_CHECKSIGFROMSTACK or rely on shortcuts like SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTSHASHVERIFY. ZmnSCPxj points out that using OP_CHECKSIGFROMSTACK can result in larger witness inputs and higher bandwidth consumption on the Bitcoin blockchain. He suggests that identifying common patterns of usage for that opcode and proposing them as specific "optimized" opcodes could be a better approach.
Updated on: 2023-06-13T18:59:42.743083+00:00