Published on: 2021-07-06T18:53:32+00:00
The conversation revolves around the implementation of the `OP_CHECKSIGFROMSTACK` opcode and the different options available to split R and S values or variable-length messages. The four options discussed are making a new 64 byte PK standard, splitting (R,S), using different opcodes, and CAT. Each option has its own drawbacks, such as being designed for specific use cases, requiring an extra push byte for every use, or wasting opcodes.In regards to the usefulness of `CHECKSIGFROMSTACKADD`, Pieter Wuille suggests that it could be useful for doing a 2-of-3 between Alice, Bob, and an Oracle signed value. However, he suggests leaving it out until there is a specific use case for it. He also explains the benefits of using the non-prehashed argument in `CHECKSIGFROMSTACK`, such as faster signing oracles and improved privacy.Jeremy Rubin expresses his thoughts on sophisticated covenants and the need to ensure that enabling them does not require jumping through too many hoops. He believes that validation costs can be kept in check and individuals should have the freedom to burn their coins if they choose. He emphasizes the importance of specific additions not introducing unintended consequences.The Elements Project is working on updating the OP_CHECKSIGFROMSTACK implementation for tapscript on Elements. This new implementation would use BIP-0340 schnorr signatures, which support variable-length messages and batch verification. Jeremy requests links to the updated spec and Russell O'Connor provides details about the plan and implementation. It is believed that this design would be suitable for Bitcoin as well.There is a discussion about adapting the "CheckDataSig" specification for a BIP in Bitcoin using 2 OP_SUCCESSX opcodes. The email reproduces the Bitcoin Cash specification and lists design questions worth considering for modifications. The proposal aims to introduce more complex smart contract functionality on the Bitcoin Cash network.Overall, the conversation covers various aspects of implementing OP_CHECKSIGFROMSTACK and its potential applications, the usefulness of CHECKSIGFROMSTACKADD, the benefits of variable-length messages in BIP-0340 schnorr signatures, and the adaptation of the "CheckDataSig" specification for Bitcoin.The activation of the protocol upgrade and the presence of at least three items on the stack are essential for the successful execution of OP_CHECKDATASIGVERIFY. Additionally, the public key and signature must be validly encoded, and the signature must pass the Low S check and signature validation.If a transaction containing OP_CHECKDATASIGVERIFY is included in a block where the median timestamp of the previous 11 blocks is less than 1542300000, it will be invalidated unless it occurs within an unexecuted OP_IF branch.The specification for OP_CHECKDATASIGVERIFY is based on Andrew Stone's OP_DATASIGVERIFY proposal. However, it has been modified through peer-review and feedback to ensure its effectiveness.For those interested in further understanding, a C++ implementation of OP_CHECKDATASIGVERIFY is provided by Bitcoin ABC. References to related concepts and proposals like OP_CHECKSIG, Strict DER Encoding, Low-S and Nullfail Specification, as well as Andrew Stone's article on Scripting, are also available for additional information and context.Overall, the proper activation of the protocol upgrade, the validity of the public key and signature, and adherence to specific conditions during block inclusion are crucial for the successful execution and validation of transactions involving OP_CHECKDATASIGVERIFY.
Updated on: 2023-08-02T04:19:47.628039+00:00