Published on: 2017-05-22T16:43:11+00:00
The user is requesting the implementation of an OP_CAT instruction that concatenates hash outputs together. This instruction would pop N vectors of the stack, concatenate them, and hash them. The user suggests that the instruction should have a maximum output size of 512 Bytes and should be able to handle input vectors of any size without exceeding 32 Bytes of memory usage. The purpose of this instruction is to securely and compactly verify many hashes and hash preimages in offchain Tumblebit transactions.In an email conversation between Ethan Heilman and Peter Todd, Ethan proposes the use of OP_CAT to reduce the size of transactions for offchain Tumblebit transactions. With OP_CAT, only one hash would need to be stored in the transaction instead of multiple hashes. This would significantly reduce the size of the transaction. Peter asks about the maximum output size and suggests that Ethan's proposal could be a good use-case for a BIP.The author of a Bitcoin development mailing list post is also requesting the implementation of OP_CAT. They believe that OP_CAT would help securely and compactly verify many hashes and hash preimages, reducing the size of Tumblebit transactions. Currently, when checking a transaction that releases multiple preimages, each preimage and its corresponding hash must be stored and checked individually. However, with OP_CAT, only one hash would need to be stored in the transaction. The author suggests an example formula for the hash calculation using OP_CAT. They acknowledge that most of the existing math OP codes are not helpful due to their 32-bit nature and strange overflow behavior.Another participant in the Bitcoin development mailing list, Mark Boldyrev, suggests reintroducing the "disabled" opcodes to enhance script flexibility and allow for the creation of sophisticated native smart contracts. Boldyrev believes that these opcodes should be reintroduced along with a standardized behavior definition. He gives an example of how the script should exit and fail when an opcode results in an arithmetic error, such as OP_DIV with a zero divisor. He also suggests that string splice opcodes should check their arguments for correctness. Boldyrev mentions that these opcodes would enable the creation of advanced smart contracts and refers to the CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY bip as examples.Re-enabling the old OP-codes in Bitcoin would require a hard fork, but if SegWit is enabled, new OP-codes can be allocated via a soft fork by introducing a new version of Script. The Elements alpha project has experimented with re-enabling the old OP-codes. There was a bug in Core software back in 2010 that allowed denial-of-service attacks due to the software crashing while executing a script on some machines. Mark Boldyrev emphasizes the need for reintroducing the removed opcodes along with standardized behavior definitions to enhance script flexibility and enable the creation of sophisticated native smart contracts. These opcodes should handle cases like arithmetic errors and incorrect arguments in a controlled manner.Overall, the implementation of OP_CAT, along with the reintroduction of disabled opcodes and standardized behavior definitions, would greatly enhance the flexibility of scripts and allow for the creation of more advanced smart contracts in Bitcoin.
Updated on: 2023-08-01T20:38:48.401828+00:00