OP_CAT is an opcode within the Bitcoin scripting language and was introduced in a very early version of Bitcoin. It was already present in the first commit 4405b78 of the Bitcoin GitHub repository.

What is an opcode?

An opcode (operation code) is a command in Bitcoin's scripting language that executes specific operations. These include arithmetic processes, data manipulation, and criteria for transaction validation.

Function of OP_CAT:

OP_CAT is utilized for concatenation. It combines the top two items from the script's stack into one. For example, if "abc" and "123" are at the top of the stack, OP_CAT concatenates them to form "abc123".

Below is a simulated Bitcoin stack. Currently, the top two items on the stack are the strings "abc" and "123". This interactive demo allows you to execute the OP_CAT opcode and see its effect on these stack items.

Press 'OP_CAT' to concatenate "abc" and "123" into a single item on the stack.

In Bitcoin's early development, OP_CAT was an active opcode. However, in 2010, developers chose to disable it, primarily due to security concerns.

The key issue with OP_CAT was its capability to create stack elements of exponentially increasing size in relation to the size of the script itself. Such functionality posed a significant threat to the network's stability. Scripts utilizing OP_CAT could potentially generate transactions that were very large or complex, thereby causing network performance and memory issues.

This concern was especially relevant when OP_CAT was used in combination with OP_DUP, an opcode that duplicates the top item on the stack. For instance, if 'X' is at the top of the stack, executing OP_DUP would result in two 'X's on top of the stack, doubling the data with each execution in combination with OP_CAT.

This interactive section features another Bitcoin stack with a single item "X" at the top. Experience firsthand how the OP_DUP opcode functions within the Bitcoin scripting environment.

Press 'OP_DUP' to see how it duplicates the top item on the stack, effectively doubling "X".

In this interactive demo, you'll see how the combination of OP_CAT and OP_DUP can lead to rapidly growing stack sizes. Being evaluated on a bitcoin node, this could significantly slow down or even halt node processing.

Use 'OP_DUP' to duplicate the top item on the stack and 'OP_CAT' to concatenate the top two items. Please proceed with caution; repeatedly executing these operations can cause similar slowdowns or freezing in your browser, reflecting the real-world impact this would have on an actual Bitcoin node.

To address these concerns, on July 29th, 2010, Satoshi introduced a stack size item limit of 5000 bytes in commit 757f076. This commit also included a change to OP_CAT where it would fail if the concatenated item exceeded this 5000 byte limit.

case OP_CAT:
{
    for (int i = 0; i < vch1.size(); i++)
        vch1[i] |= vch2[i];
    // (x1 x2 -- out)
    if (stack.size() < 2)
        return false;
    valtype& vch1 = stacktop(-2);
    valtype& vch2 = stacktop(-1);
    vch1.insert(vch1.end(), vch2.begin(), vch2.end());
    stack.pop_back();
    if (stacktop(-1).size() > 5000)
        return false;
}

Let's install this update to your system. Click 'Install' to proceed.

Only two days later, on July 31st, 2010, Satoshi introduced a limit of 200 opcodes to be evaluated within one transaction. This limit was introduced in commit 6ff5f71, likely to increase security even further.

if (opcode > OP_16 && nOpCount++ > 200)
    return false;

Let's install this update to your system. Click 'Install' to proceed.

With the limit of 200 opcodes per script and 5000 bytes per stack item in place, the risk of stack growth is mitigated.

For demonstration, there is a counter that keeps track of the number of opcodes executed. The script will fail if the counter exceeds 200 or if the result of OP_CAT exceeds the 5000 bytes limit.

Two weeks later, on July 31st, 2010, Satoshi deactivated various opcodes, including OP_CAT, and simultaneously introduced a stack item size limit of 520 bytes (from the previous 2000 bytes) in commit 4bd188c. There is no clear explanation given for this change. The commit message only states "misc changes" and no further comments are in the code. With a stack item size limit of 520 bytes, the memory risks of OP_CAT are even further mitigated, so it's not quite clear what the real reason for its deactivation was at the time.

if (opcode == OP_CAT ||
    opcode == OP_SUBSTR ||
    opcode == OP_LEFT ||
    ...
    return false;

There are many discussions and also misconceptions about the deactivation of OP_CAT. Yes, initially, in 2009, OP_CAT could easily cause memory overflow issues. Especially in combination with OP_DUP, it could lead to exponential growth of the stack size. However, with the introduction of the 5000/520 byte limit and the 200 opcode limit, these risks were mitigated. So why was OP_CAT deactivated?

Click 'Deactivate OP_CAT' to follow Satoshi's decision.

Today, 14 years after its deactivation, OP_CAT is still deactivated. While we can't ask Satoshi why he made this decision, we can look at the current state of Bitcoin and its scripting language. The latest upgrade to Bitcoin was the Taproot upgrade (which went into full effect in 2021), offering crucial enhancements to the Bitcoin protocol. While Taproot itself is a broader upgrade improving Bitcoin's privacy and efficiency, it also introduced Tapscript, which specifically addresses script execution and security. Among many things, it lifted the opcode limit per script and also lifted the overall script size limit, enabling longer and more complex scripts. It still has the 520 byte stack item size limit in place.

Let's upgrade to Taproot and re-evaluate our decisions. Click 'Upgrade to Taproot' to proceed.

While OP_CAT remains disabled in Bitcoin scripting, the Tapscript upgrade, with its 520-byte size limit, provides a framework that could reintroduce OP_CAT safely in the future.

For demonstration, let's explore a simulated environment where you can use OP_CAT in conjunction with OP_DUP without the risk of creating an oversized stack. Tapscript's size limit of 520 bytes is applied here to prevent excessive growth. Furthermore, there are no restrictions to the number of opcodes per script.

Let's reiterate. OP_CAT was deactivated in 2010. This is likely due to security risks regarding memory and stack size issues. Yet, Satoshi already introduced useful mitigations to these risks in 2010. Fast forward 14 years, and some of these measures are still in place; others have changed. We still have the 520 byte stack item size limit, but the opcode limit is gone. With Tapscript, there is also no longer any limit on the size of scripts in general.

These changes allowed for the creation of Ordinals through the ability to create large transactions like inscribing a 3.92MB Taproot Wizard. Within these current rules, we can't really do any more harm with OP_CAT than we do with any other kind of transaction, at least in terms of transaction size.

So, should OP_CAT be reactivated? Well, this is up to all of us to decide. Proponents of OP_CAT point out interesting advantages. Examples include covenants (ability to restrict the spending of tokens after you sent them), vaults (ways to better custody your bitcoin), post-quantum proof Bitcoin using Lamport Signatures, and improved bridges like the one proposed through CatVM for connecting Bitcoin layer two solutions.

This concludes the OP_CAT setup wizard. You've gained insights into opcodes, specifically OP_CAT and OP_DUP, the deactivation of OP_CAT and the reasons for it. You learned about how Bitcoin changed and how OP_CAT could be reintroduced in the future.

Armed with this knowledge, you're now equipped to contribute meaningfully to the ongoing dialogue about Bitcoin's evolution.

Click 'Finish' to end and restart the setup wizard (this will reload the whole website).