Thoughts on gmaxwell's take about OP_CAT and the 2024 'Great script restoration'?

Anyone know what gmaxwell thinks about OP_CAT and the whole "Great script restoration" thing? It seems to be pushed by a mix of spammers and some Core devs who are saying this new approach is "objectively" safe with some limits and checks. But I found an old thread from 2014 where he mentioned that even with those "limits" there are risks involved. So what’s making the devs so confident about safety this time around?

Well how about directly asking him.... Just *how* is anyone else supposed to know another persons thoughts........

About time we brought back all the OP_codes.. Still don't believe this message was from Satoshi... I think people here know more than they be letting on about the removal of some of the codes. Something to hide lads?

Why would it matter? Gmaxwell does not even work on Bitcoin anymore. And it's not like he was the only person you needed to get an approval from in order to get features in. That's why it's called a consensus, as most developers need to agree on something to let it pass.

OP, care to disclose your identity?  (or at least one you're better known by)

I'm also curious fwiw

In any case, the OP's link is highly misleading.  In that thread I'm commenting on someone thinking that being able to run a limited number of operations in total counted as "a limit" and I point out that it's not a sufficient one.  But it was just a rando's question.  It's not difficult in any sense to implement a sensible limit (and in fact this was done in the elements test network and eventually copied into other bitcoin based blockchains like bcash).

This old topic was from 2014. We didn't have Segwit or Taproot then. It was very unclear, how to make an upgrade, which could be used to enable OP_CAT, without affecting the original Script. However, here and now, Taproot can show us, that it is possible to introduce for example OP_SUCCESS into TapScript, without touching the old Script (and the same with disabling OP_CHECKMULTISIG(VERIFY), without touching existing transactions). Which means, that one new address type (Taproot) can be used to deploy completely new script, with completely new rules, even if most of them are similar to the old approach. Also, after all of those years, it is still unclear, which change would be activated first. Because the same thing can be done in a different way. There are at least some competing proposals, and if we activate OP_CAT, then why would we need OP_CHECKSIGFROMSTACK? What about SIGHASH_ANYPREVOUT? What about OP_CHECKTEMPLATEVERIFY? There are many different approaches, and today, it is still not fully clear, which option would win.

Actually I believe OP_CAT is required for many reasons outlined below some which people may or may not have thought about. Below is a draft of ideas for why OP_CAT should come back. This proposes the re-introduction and standardization of the OP_CAT operation in Bitcoin Script. OP_CAT concatenates two stack items and can significantly enhance the flexibility and functionality of Bitcoin scripts. By allowing scripts to combine multiple data elements directly on the stack, OP_CAT can streamline complex operations, reducing the need for more convoluted and error-prone workarounds. This proposal details the opcode's utility through four specific use cases: multi-signature time-locked escrows, conditional multi-party agreements, atomic swaps, and proof-of-ownership verifications. These examples demonstrate the enhanced capabilities and efficiencies that OP_CAT can bring to Bitcoin scripting, enabling more sophisticated financial contracts and decentralized applications. Motivation Bitcoin Script currently lacks a native concatenation operation, significantly limiting its capability to handle complex conditional logic efficiently. The absence of OP_CAT forces developers to rely on more cumbersome and error-prone methods to achieve similar outcomes. This not only increases the risk of scripting errors but also makes scripts more challenging to audit and maintain, reducing overall script reliability and security. The re-introduction of OP_CAT would enable more sophisticated scripting possibilities, thereby supporting a wider range of financial contracts and decentralized applications. By simplifying the concatenation process, OP_CAT can enhance the expressiveness of Bitcoin scripts, making it easier to implement advanced features such as atomic swaps, multi-party agreements, and time-locked contracts. These capabilities are essential for creating innovative decentralized financial products that can operate efficiently on the Bitcoin network. Advanced scripting possibilities brought by OP_CAT will foster innovation within the Bitcoin ecosystem. For example, atomic swaps, which enable the exchange of different cryptocurrencies without a trusted third party, can be implemented more efficiently. Multi-party agreements, which require more complex conditional logic to ensure that all parties' conditions are met before a transaction is finalized, can also be simplified. Time-locked contracts, which control the timing of transactions, will benefit from the more straightforward implementation of concatenated scripts. Moreover, this proposal addresses the security concerns associated with the original OP_CAT operation. The re-introduced OP_CAT includes robust error handling and validation measures to ensure secure and reliable script execution. These measures are designed to prevent the vulnerabilities that led to the initial removal of OP_CAT, providing a secure environment for advanced scripting. This expansion of scripting capabilities is crucial for the continued evolution and adoption of Bitcoin as a programmable digital currency. As Bitcoin aims to compete with other programmable blockchain platforms, enhancing its scripting language is essential to attracting developers and fostering a vibrant ecosystem of decentralized applications. By making Bitcoin Script more powerful and versatile, OP_CAT can play a significant role in enabling new use cases in decentralized finance, thereby driving the next wave of Bitcoin innovation. In summary, reintroducing OP_CAT to Bitcoin Script addresses current limitations, enhances script expressiveness, supports advanced financial contracts, and ensures secure execution. This proposal not only fosters innovation and broadens the range of possible applications but also aligns with Bitcoin's ongoing evolution as a leading programmable digital currency. Specification Use Cases Multi-Signature Time-Locked Escrow Alice deposits funds into an escrow that Bob can access if both Alice and Bob sign off, or Charlie can arbitrate if needed. If a certain time passes without resolution, funds automatically return to Alice. This complex conditional transaction is efficiently managed using OP_CAT to concatenate and evaluate conditions based on signatures, public keys, and a locktime. In this scenario, Alice wants to ensure that her funds are secure in an escrow arrangement that can only be released under specific conditions. Here’s how the script is structured to manage these conditions: Initial Stack Setup: The stack starts with Alice’s signature (sig1), Bob’s signature (sig2), Alice’s public key (pubkeyA), Bob’s public key (pubkeyB), Charlie’s public key (pubkeyC), and the locktime. Condition 1: Alice and Bob Agreement: The script first checks if Alice’s public key matches the provided key. If Alice’s key matches (OP_DUP <pubkeyA> OP_EQUAL), the script proceeds to check Bob’s public key. If Bob’s public key matches (OP_DUP <pubkeyB> OP_EQUALVERIFY), the script then uses OP_ROT and OP_CAT to concatenate the signatures and compare with the locktime. OP_ROT rotates the top three stack items, placing sig1 and sig2 in the correct positions. OP_CAT concatenates sig1 and sig2, creating a single data item for comparison. Locktime Check for Alice and Bob: The concatenated signatures are then compared with the locktime (OP_GREATERTHAN). If the combined signatures are valid and the locktime condition is satisfied, the script validates the signatures (OP_CHECKSIGVERIFY and OP_CHECKSIG), allowing Bob to access the funds. If the signatures do not meet the locktime condition, the script checks if Charlie’s hash matches (OP_HASH160 <CharlieHash> OP_EQUAL), allowing Charlie to arbitrate. Condition 2: Charlie as Arbitrator: If the initial check for Alice’s key fails, the script checks if Charlie’s key matches (OP_DUP <pubkeyC> OP_EQUALVERIFY). If Charlie’s key matches, the script proceeds similarly by rotating the stack and concatenating the conditions. The locktime is then checked to see if it is less than the current block time (OP_LESSTHAN). If Charlie’s signature and the locktime condition are valid, Charlie can sign and release the funds (OP_CHECKSIGVERIFY). Return Funds to Alice After Locktime: If none of the above conditions are met, the script defaults to returning the funds to Alice after the locktime expires. This is handled by duplicating the locktime and verifying it against the current block time (OP_DUP <locktime> OP_CHECKLOCKTIMEVERIFY). If the locktime condition is met, the script drops the locktime from the stack (OP_DROP) and verifies Alice’s key (OP_DUP <pubkeyA> OP_EQUALVERIFY). Finally, Alice’s signature is checked, and if valid, the funds are returned to her (OP_CHECKSIG). Conditional Multi-Party Agreement Alice, Bob, and Charlie enter into an agreement where funds are released based on the concatenation of conditions set by any two of the three parties. This setup can be particularly useful in complex business transactions, joint ventures, or any scenario where the approval of multiple stakeholders is required before releasing funds. This script demonstrates how OP_CAT can be used to concatenate and evaluate conditions efficiently. Initial Stack Setup: The stack initially contains two conditions (cond1 and cond2), and the public keys of Alice (pubkeyA), Bob (pubkeyB), and Charlie (pubkeyC). Conditions can represent various requirements such as specific signatures, hash pre-images, or other data necessary for the transaction. Condition 1: Alice and Bob Agreement: The script starts by checking if Alice’s public key matches the provided key using OP_DUP <pubkeyA> OP_EQUAL. If Alice’s key matches, the script then checks if Bob’s public key also matches using OP_DUP <pubkeyB> OP_EQUALVERIFY. If both keys match, indicating that Alice and Bob are in agreement, the script rotates the top three stack items using OP_ROT to prepare for concatenation. OP_CAT is used to concatenate cond1 and cond2, forming a single condition.

OK, after getting an understanding of gmaxwell's sentiment towards OP_CAT, does that suggest that Andrew Poelstra might be wrong? Or do BOTH sides of the debate here have valid points? I've read that OP_CAT is "narrower upgrade than Taproot", which then should also be "narrower than Segwit" because there are really no changes made, it's merely using the existing script scheme to make a new opcode. But I'm a pleb, and the stupid one in the forum, but I'm curious.

wtf? why do you let people fucking lie to you like this.

Does anyone know what Ja Rule thinks?

I'm sorry for making wrong assumption, and jumping to the conclusion that there was "someone wrong" in this instance, or if it's even "a debate". Perhaps the problem is because Bitcoin doesn't have an inherent mechanism that's built for protocol updates, and probably also for consensus changes.