-
-
Save udevswap/b768d20d62549922b9e72428ef9eb608 to your computer and use it in GitHub Desktop.
| OP_CAT seems to be the most simple yet powerful way to enable general purpose smart contract on Bitcoin. | |
| There has been plentiful of discussions, tests regarding its capability and security. | |
| OP_CAT enables zero-knowledge proof which further allows rollup layer2s on top of Bitcoin, less important transactions can happen on layer2s instead of Bitcoin mainnet. Starknet, which is one of the most talented team researching on zk and rollup technology has already confirmed that they are able to build a layer2 based on their technology if OP_CAT is enabled | |
| Enabling OP_CAT brings least security risk with most desirable outcome of pure decentralized bridges, rollup layer2s and smartcontract on Bitcoin. |
OP_CTV
OP_CTV restricts funds to be spent only through a transaction that conforms to a predefined template. However, it has limitations: It supports only a limited type of covenant, designed specifically to improve the functionality of specific-purpose transactions, making it less general-purpose. Most importantly, It does not support recursive covenants.
OP_CSFS
is a proposed Bitcoin opcode designed to enhance Bitcoin Script by enabling the verification of a signature against arbitrary data rather than the entire transaction data. While it can be emulated using OP_CAT and OP_CHECKSIG, a standalone OP_CSFS would be more efficient. OP_CAT achieves the same of what OP_CSFS does but OP_CAT does more.
OP_VAULT
Specifically designed for vault functionality, but this can also be implemented using OP_CAT, making OP_VAULT unnecessary in some scenarios. OP_CAT achieves the purpose of OP_VAULT and enables more use cases.
TXHASH:
A strict superset of OP_CTV, offering greater flexibility. However, it remains limited, what TXHASH does can also be done with OP_CAT. With OP_CAT, it can become more powerful by enabling introspection of not only the current spending transaction but also its parent transactions.
SIGHASH_APO:
Primarily tailored to optimize Lightning Network use cases. Any op_code that is not general-purpose should not be considered because it can be done by a more general-purpose op_code, a specific-purpose op_code is not important enough to perform a soft fork
You haven't mentioned anything about other opcodes and SIGHASH_APO in the rationale. Please review the other rationales, re-evaluate the proposals, and update the wiki accordingly.