From 83ca57f22268edb1ff2815085a4383ba8d1b55fe Mon Sep 17 00:00:00 2001 From: Ethan Heilman Date: Mon, 11 Dec 2023 18:11:22 -0500 Subject: [PATCH 01/53] Create bip-???-cat.mediawiki --- bip-???-cat.mediawiki | 89 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 bip-???-cat.mediawiki diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki new file mode 100644 index 0000000000..8cd7baae1b --- /dev/null +++ b/bip-???-cat.mediawiki @@ -0,0 +1,89 @@ +
+  BIP: ???
+  Layer: Consensus (soft fork)
+  Title: OP_CAT
+  Author: Ethan Heilman 
+          Armin Sabouri 
+  Status: Draft
+  Type: Standards Track
+  Created: 2023-10-21
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-op-cat
+  License: BSD-3-Clause
+
+ +==Abstract== + +This BIP defines OP_CAT a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126. + +When evaluated the OP_CAT instruction: +# Pops the top two values off the stack, +# concatenate the popped values together, +# and then pushes the concatenated value on the top of the stack. + +OP_CAT fails if there are less than two values on the stack or if a concatenated value would have a combined size of greater than the maximum script element size of 520 Bytes. + +==Motivation== +Bitcoin tapscript lacks a general purpose way of combining objects on the stack restricting the expressiveness and power of tapscript. For instance this prevents among many other things the ability to construct and evaluate merkle trees and other hashed data structures in tapscript. OP_CAT by adding a general purpose way to concatenate stack values would overcome this limitation and greatly increase the functionality of tapscript. + +OP_CAT aims to expands the toolbox of the tapscript developer with a simple, modular and useful opcode in the spirit of Unix R. Pike and B. Kernighan, "Program design in the UNIX environment", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable: + +* Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf +* Tree Signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions. P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/ +* Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport signatures merely requires the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html +* Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols. +* Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficent to build vaults in Bitcoin. +* Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md. + +The opcode OP_CAT was available in early versions of Bitcoin. However OP_CAT was removed because it enabled the construction of a script for which an evaluation could have memory usage exponential in the size of the script. +For instance a script which pushed an 1 Byte value on the stack then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack value whose size was greater than 1 Terabyte. This is no longer an issue because tapscript enforces a maximum stack element size of 520 Bytes. + +==Specification== + +OP_CAT pops two elements of the stack, concatenates them together in stack order and pushes the resultant element onto the stack. Given the stack [x1,x2], where x2 is at the top of the stack, OP_CAT will push x1||x2 onto the stack. By '||' we denote concatenation. + +Implementation +
+case OP_CAT:
+{
+    if (stack.size() < 2)
+        return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
+    valtype& vch1 = stacktop(-2);
+    valtype& vch2 = stacktop(-1);
+    if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
+        return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
+    vch1.insert(vch1.end(), vch2.begin(), vch2.end());
+    stack.pop_back();
+}
+break;
+
+This implementation is inspired by the original implementation of OP_CAT as shown below. Alternative implementation of OP_CAT can be found in Elements Roose S., Elements Project, "Re-enable several disabled opcodes", 2019, https://github.com/ElementsProject/elements/commit/13e1103abe3e328c5a4e2039b51a546f8be6c60a#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R740-R759. + +The value of MAX_SCRIPT_ELEMENT_SIZE is 520 Bytes + +==Notes== + +OP_CAT as it existed in the Bitcoin codebase prior to the commit "misc changes" 4bd188cS. Nakamoto, "misc changes", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefL381 which disabled it. + +
+  // (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;
+  }
+
+ +==References== + + + +==Acknowledgements== + +We wish to acknowledge Dan Gould for encouraging and helping review this effort. + +== Copyright == +This document is placed in the public domain. From f1169dd1fc067825c56016379a8b84c033b6eeb2 Mon Sep 17 00:00:00 2001 From: Ethan Heilman Date: Tue, 12 Dec 2023 08:24:39 -0500 Subject: [PATCH 02/53] Fixes typo Co-authored-by: kallewoof --- bip-???-cat.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki index 8cd7baae1b..281fa3c535 100644 --- a/bip-???-cat.mediawiki +++ b/bip-???-cat.mediawiki @@ -39,7 +39,7 @@ For instance a script which pushed an 1 Byte value on the stack then repeated th ==Specification== -OP_CAT pops two elements of the stack, concatenates them together in stack order and pushes the resultant element onto the stack. Given the stack [x1,x2], where x2 is at the top of the stack, OP_CAT will push x1||x2 onto the stack. By '||' we denote concatenation. +OP_CAT pops two elements off the stack, concatenates them together in stack order and pushes the resulting element onto the stack. Given the stack [x1,x2], where x2 is at the top of the stack, OP_CAT will push x1||x2 onto the stack. By '||' we denote concatenation. Implementation 

From 26e8e5f7fc1f51e6ba861de7a25524e1b561a08d Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Tue, 12 Dec 2023 08:26:36 -0500
Subject: [PATCH 03/53] Better fits bitcoin style guide

"If an if only has a single-statement then-clause, it can appear on the same line as the if, without braces. In every other case, braces are required, and the then and else clauses must appear correctly indented on a new line."

Co-authored-by: kallewoof 
---
 bip-???-cat.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 281fa3c535..05f16d651b 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -45,8 +45,9 @@ Implementation
 
 case OP_CAT:
 {
-    if (stack.size() < 2)
+    if (stack.size() < 2) {
         return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
+    }
     valtype& vch1 = stacktop(-2);
     valtype& vch2 = stacktop(-1);
     if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)

From 0335c9d18813f3a18cff9f9b776432114f6a570c Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Tue, 12 Dec 2023 08:27:35 -0500
Subject: [PATCH 04/53] Grammar fix

Co-authored-by: kallewoof 
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 05f16d651b..6833621100 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -57,7 +57,7 @@ case OP_CAT:
 }
 break;
 

-This implementation is inspired by the original implementation of OP_CAT as shown below. Alternative implementation of OP_CAT can be found in Elements Roose S., Elements Project, "Re-enable several disabled opcodes", 2019, https://github.com/ElementsProject/elements/commit/13e1103abe3e328c5a4e2039b51a546f8be6c60a#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R740-R759.
+This implementation is inspired by the original implementation of OP_CAT as shown below. An alternative implementation of OP_CAT can be found in Elements Roose S., Elements Project, "Re-enable several disabled opcodes", 2019, https://github.com/ElementsProject/elements/commit/13e1103abe3e328c5a4e2039b51a546f8be6c60a#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R740-R759.
 
 The value of MAX_SCRIPT_ELEMENT_SIZE is 520 Bytes
 

From 3d31e5c8947bf5d2d8ba02dc22c5302085b9f91b Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Tue, 12 Dec 2023 08:59:03 -0500
Subject: [PATCH 05/53] Adds brackets

Co-authored-by: kallewoof 
---
 bip-???-cat.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 6833621100..584f697f60 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -50,8 +50,9 @@ case OP_CAT:
     }
     valtype& vch1 = stacktop(-2);
     valtype& vch2 = stacktop(-1);
-    if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
+    if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE) {
         return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
+    }
     vch1.insert(vch1.end(), vch2.begin(), vch2.end());
     stack.pop_back();
 }

From bb725e652357f2502fba3cd8e2e8fa92e40ca706 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 14 Dec 2023 23:43:42 -0500
Subject: [PATCH 06/53] Wording

Co-authored-by: kallewoof 
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 584f697f60..40b4cc55a8 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -13,7 +13,7 @@
 
 ==Abstract==
 
-This BIP defines OP_CAT a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126.
+This BIP reintroduces OP_CAT in the form of a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126.
 
 When evaluated the OP_CAT instruction:
 # Pops the top two values off the stack,

From 9779dc9920eeacbf39a9b53e5165423551de209e Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 14 Dec 2023 23:44:14 -0500
Subject: [PATCH 07/53] Keeps past tense consistant

Co-authored-by: kallewoof 
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 40b4cc55a8..1beb7c565e 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -17,7 +17,7 @@ This BIP reintroduces OP_CAT in the form of a new tapscript opcode which allows
 
 When evaluated the OP_CAT instruction:
 # Pops the top two values off the stack,
-# concatenate the popped values together,
+# concatenates the popped values together,
 # and then pushes the concatenated value on the top of the stack.
 
 OP_CAT fails if there are less than two values on the stack or if a concatenated value would have a combined size of greater than the maximum script element size of 520 Bytes.

From c5d66d670671dbac8265b5588f3de8e1ca4f3972 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 14 Dec 2023 23:44:44 -0500
Subject: [PATCH 08/53] Better phrasing

Co-authored-by: kallewoof 
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 1beb7c565e..c84680acaf 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -20,7 +20,7 @@ When evaluated the OP_CAT instruction:
 # concatenates the popped values together,
 # and then pushes the concatenated value on the top of the stack.
 
-OP_CAT fails if there are less than two values on the stack or if a concatenated value would have a combined size of greater than the maximum script element size of 520 Bytes.
+OP_CAT fails if there are less than two values on the stack or if a concatenated value would have a combined size greater than the maximum script element size of 520 Bytes.
 
 ==Motivation==
 Bitcoin tapscript lacks a general purpose way of combining objects on the stack restricting the expressiveness and power of tapscript. For instance this prevents among many other things the ability to construct and evaluate merkle trees and other hashed data structures in tapscript. OP_CAT by adding a general purpose way to concatenate stack values would overcome this limitation and greatly increase the functionality of tapscript.

From 848352f40875e43ba7fd5ecabb63272f165fcd4a Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 14 Dec 2023 23:45:04 -0500
Subject: [PATCH 09/53] Phrasing

Co-authored-by: kallewoof 
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index c84680acaf..d921524315 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -23,7 +23,7 @@ When evaluated the OP_CAT instruction:
 OP_CAT fails if there are less than two values on the stack or if a concatenated value would have a combined size greater than the maximum script element size of 520 Bytes.
 
 ==Motivation==
-Bitcoin tapscript lacks a general purpose way of combining objects on the stack restricting the expressiveness and power of tapscript. For instance this prevents among many other things the ability to construct and evaluate merkle trees and other hashed data structures in tapscript. OP_CAT by adding a general purpose way to concatenate stack values would overcome this limitation and greatly increase the functionality of tapscript.
+Bitcoin tapscript lacks a general purpose way of combining objects on the stack restricting the expressiveness and power of tapscript. This prevents among many other things the ability to construct and evaluate merkle trees and other hashed data structures in tapscript. OP_CAT by adding a general purpose way to concatenate stack values would overcome this limitation and greatly increase the functionality of tapscript.
 
 OP_CAT aims to expands the toolbox of the tapscript developer with a simple, modular and useful opcode in the spirit of Unix R. Pike and B. Kernighan, "Program design in the UNIX environment", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable:
 

From a2b0100671f492628ce219d706fa71a506ca0475 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 14 Dec 2023 23:47:36 -0500
Subject: [PATCH 10/53] Typo

Co-authored-by: kallewoof 
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index d921524315..32595c33c8 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -29,7 +29,7 @@ OP_CAT aims to expands the toolbox of the tapscript developer with a simple, mod
 
 * Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf
 * Tree Signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
-* Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport signatures merely requires the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html
+* Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html
 * Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
 * Vaults  M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficent to build vaults in Bitcoin.
 * Replicating CheckSigFromStack  A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298  which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.

From 6a790ec52635a7aa52cc2c20dc25a9236daae5f8 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 14 Dec 2023 23:47:50 -0500
Subject: [PATCH 11/53] Removes space in ref

Co-authored-by: kallewoof 
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 32595c33c8..cd952c82e7 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -31,7 +31,7 @@ OP_CAT aims to expands the toolbox of the tapscript developer with a simple, mod
 * Tree Signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
 * Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html
 * Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
-* Vaults  M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficent to build vaults in Bitcoin.
+* Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficent to build vaults in Bitcoin.
 * Replicating CheckSigFromStack  A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298  which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.
 
 The opcode OP_CAT was available in early versions of Bitcoin. However OP_CAT was removed because it enabled the construction of a script for which an evaluation could have memory usage exponential in the size of the script.

From 01db3acab0830a43b526c6c5c0a8daad77704d7b Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 14 Dec 2023 23:47:58 -0500
Subject: [PATCH 12/53] Removes space in ref

Co-authored-by: kallewoof 
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index cd952c82e7..9e98da0fd9 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -32,7 +32,7 @@ OP_CAT aims to expands the toolbox of the tapscript developer with a simple, mod
 * Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html
 * Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
 * Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficent to build vaults in Bitcoin.
-* Replicating CheckSigFromStack  A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298  which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.
+* Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.
 
 The opcode OP_CAT was available in early versions of Bitcoin. However OP_CAT was removed because it enabled the construction of a script for which an evaluation could have memory usage exponential in the size of the script.
 For instance a script which pushed an 1 Byte value on the stack then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack value whose size was greater than 1 Terabyte. This is no longer an issue because tapscript enforces a maximum stack element size of 520 Bytes.

From 945e2a374249114c313d6204d7db61dfe496fe97 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 14 Dec 2023 23:48:46 -0500
Subject: [PATCH 13/53] Typos

TIL that it is "a one" rather than "an one"

Co-authored-by: kallewoof 
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 9e98da0fd9..ef026fd6fe 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -35,7 +35,7 @@ OP_CAT aims to expands the toolbox of the tapscript developer with a simple, mod
 * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.
 
 The opcode OP_CAT was available in early versions of Bitcoin. However OP_CAT was removed because it enabled the construction of a script for which an evaluation could have memory usage exponential in the size of the script.
-For instance a script which pushed an 1 Byte value on the stack then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack value whose size was greater than 1 Terabyte. This is no longer an issue because tapscript enforces a maximum stack element size of 520 Bytes.
+For instance a script which pushed a 1 Byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack value whose size was greater than 1 Terabyte. This is no longer an issue because tapscript enforces a maximum stack element size of 520 Bytes.
 
 ==Specification==
 

From 7180c1cf8c478ed53ee65705e34fc61975f96239 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 15 Dec 2023 09:54:50 -0500
Subject: [PATCH 14/53] Prefer bytes to Bytes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index ef026fd6fe..2a39158b98 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -20,7 +20,7 @@ When evaluated the OP_CAT instruction:
 # concatenates the popped values together,
 # and then pushes the concatenated value on the top of the stack.
 
-OP_CAT fails if there are less than two values on the stack or if a concatenated value would have a combined size greater than the maximum script element size of 520 Bytes.
+OP_CAT fails if there are less than two values on the stack or if a concatenated value would have a combined size greater than the maximum script element size of 520 bytes.
 
 ==Motivation==
 Bitcoin tapscript lacks a general purpose way of combining objects on the stack restricting the expressiveness and power of tapscript. This prevents among many other things the ability to construct and evaluate merkle trees and other hashed data structures in tapscript. OP_CAT by adding a general purpose way to concatenate stack values would overcome this limitation and greatly increase the functionality of tapscript.

From 6f5a74d83e621ded090f436a3cc407dc705ad132 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 15 Dec 2023 10:04:36 -0500
Subject: [PATCH 15/53] Increases conciseness and clarity
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 2a39158b98..92b2588e8a 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -34,7 +34,7 @@ OP_CAT aims to expands the toolbox of the tapscript developer with a simple, mod
 * Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficent to build vaults in Bitcoin.
 * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.
 
-The opcode OP_CAT was available in early versions of Bitcoin. However OP_CAT was removed because it enabled the construction of a script for which an evaluation could have memory usage exponential in the size of the script.
+The opcode OP_CAT was available in early versions of Bitcoin. However OP_CAT was removed because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script.
 For instance a script which pushed a 1 Byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack value whose size was greater than 1 Terabyte. This is no longer an issue because tapscript enforces a maximum stack element size of 520 Bytes.
 
 ==Specification==

From d4f85b11464a60961962960b306cac72461a977f Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 15 Dec 2023 14:44:07 -0500
Subject: [PATCH 16/53] Lowercase bytes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 92b2588e8a..ec4834a2e9 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -35,7 +35,7 @@ OP_CAT aims to expands the toolbox of the tapscript developer with a simple, mod
 * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.
 
 The opcode OP_CAT was available in early versions of Bitcoin. However OP_CAT was removed because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script.
-For instance a script which pushed a 1 Byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack value whose size was greater than 1 Terabyte. This is no longer an issue because tapscript enforces a maximum stack element size of 520 Bytes.
+For example, a script that pushed a 1-byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack value whose size was greater than 1 terabyte. This is no longer an issue because tapscript enforces a maximum stack element size of 520 bytes.
 
 ==Specification==
 

From beb5802cc6c5f28da1aeaf0f75eb59738a004fb9 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 15 Dec 2023 15:27:22 -0500
Subject: [PATCH 17/53] Adds subsection header
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index ec4834a2e9..6a5c54a05a 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -41,7 +41,7 @@ For example, a script that pushed a 1-byte value on the stack and then repeated
 
 OP_CAT pops two elements off the stack, concatenates them together in stack order and pushes the resulting element onto the stack. Given the stack [x1,x2], where x2 is at the top of the stack, OP_CAT will push x1||x2 onto the stack. By '||' we denote concatenation.
 
-Implementation
+===Implementation===
 
 case OP_CAT:
 {

From 0a143d396910a49225c6fc2f487a968dc6e96035 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 15 Dec 2023 15:46:49 -0500
Subject: [PATCH 18/53] Use BSD-3 license

---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 6a5c54a05a..61428e34c2 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -88,4 +88,4 @@ OP_CAT as it existed in the Bitcoin codebase prior to the commit "misc changes"
 We wish to acknowledge Dan Gould for encouraging and helping review this effort. 
 
 == Copyright ==
-This document is placed in the public domain.
+This document is licensed under the 3-clause BSD license.

From 82198302cd1d36f841f1bb6cd93c3c97ecbb8a31 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 15 Dec 2023 15:52:05 -0500
Subject: [PATCH 19/53] Code formatting
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 61428e34c2..cd5b86a533 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -60,7 +60,7 @@ break;
 

 This implementation is inspired by the original implementation of OP_CAT as shown below. An alternative implementation of OP_CAT can be found in Elements Roose S., Elements Project, "Re-enable several disabled opcodes", 2019, https://github.com/ElementsProject/elements/commit/13e1103abe3e328c5a4e2039b51a546f8be6c60a#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R740-R759.
 
-The value of MAX_SCRIPT_ELEMENT_SIZE is 520 Bytes
+The value of MAX_SCRIPT_ELEMENT_SIZE is 520.
 
 ==Notes==
 

From 0b8a7e4b64458821d474fa08976a1d38d33d3004 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 15 Dec 2023 15:56:12 -0500
Subject: [PATCH 20/53] Code formatting
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index cd5b86a533..d3af82f5ed 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -39,7 +39,7 @@ For example, a script that pushed a 1-byte value on the stack and then repeated
 
 ==Specification==
 
-OP_CAT pops two elements off the stack, concatenates them together in stack order and pushes the resulting element onto the stack. Given the stack [x1,x2], where x2 is at the top of the stack, OP_CAT will push x1||x2 onto the stack. By '||' we denote concatenation.
+OP_CAT pops two elements off the stack, concatenates them together in stack order and pushes the resulting element onto the stack. Given the stack _[x1, x2]_, where _x2_ is at the top of the stack, OP_CAT will push _x1 || x2_ onto the stack. By _||_ we denote concatenation.
 
 ===Implementation===
 

From 77509f6c23a6036a3e4ac929ab2fe7c6d8dbdeec Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 15 Dec 2023 15:57:08 -0500
Subject: [PATCH 21/53] Period to colon
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index d3af82f5ed..707cf79719 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -64,7 +64,7 @@ The value of MAX_SCRIPT_ELEMENT_SIZE is 520.
 
 ==Notes==
 
-OP_CAT as it existed in the Bitcoin codebase prior to the commit "misc changes" 4bd188cS. Nakamoto, "misc changes", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefL381 which disabled it.
+OP_CAT as it existed in the Bitcoin codebase prior to the commit "misc changes" 4bd188cS. Nakamoto, "misc changes", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefL381 which disabled it:
 
 
   // (x1 x2 -- out)

From 4f39e4b9d55960432d5548fa7e52568d3051428a Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Sat, 16 Dec 2023 16:23:49 -0500
Subject: [PATCH 22/53] Avoids designing or discussing how to add post-quantum
 commitments to Bitcoin

---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 707cf79719..8709f7b607 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -29,7 +29,7 @@ OP_CAT aims to expands the toolbox of the tapscript developer with a simple, mod
 
 * Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf
 * Tree Signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
-* Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html
+* Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It is an open question if the quantum resistance of Lamport Signatures can be preserved when used in a taproot output.
 * Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
 * Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficent to build vaults in Bitcoin.
 * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.

From 97635f5c094709dd18f4afee017e33face886f5b Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Sun, 17 Dec 2023 12:49:46 -0500
Subject: [PATCH 23/53] Lowercase the signatures

---
 bip-???-cat.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 8709f7b607..68c24c962a 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -28,8 +28,8 @@ Bitcoin tapscript lacks a general purpose way of combining objects on the stack
 OP_CAT aims to expands the toolbox of the tapscript developer with a simple, modular and useful opcode in the spirit of Unix R. Pike and B. Kernighan, "Program design in the UNIX environment", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable:
 
 * Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf
-* Tree Signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
-* Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It is an open question if the quantum resistance of Lamport Signatures can be preserved when used in a taproot output.
+* Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
+* Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It is an open question if the quantum resistance of Lamport signatures can be preserved when used in a taproot output.
 * Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
 * Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficent to build vaults in Bitcoin.
 * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.

From e3dc3ba3617d33dc1c434196f5f7b4e463254e49 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Sun, 17 Dec 2023 12:53:07 -0500
Subject: [PATCH 24/53] Italicize variables
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>
---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 68c24c962a..334cc2022a 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -39,7 +39,7 @@ For example, a script that pushed a 1-byte value on the stack and then repeated
 
 ==Specification==
 
-OP_CAT pops two elements off the stack, concatenates them together in stack order and pushes the resulting element onto the stack. Given the stack _[x1, x2]_, where _x2_ is at the top of the stack, OP_CAT will push _x1 || x2_ onto the stack. By _||_ we denote concatenation.
+OP_CAT pops two elements off the stack, concatenates them together in stack order and pushes the resulting element onto the stack. Given the stack ''[x1, x2]'', where ''x2'' is at the top of the stack, OP_CAT will push ''x1 || x2'' onto the stack. By ''||'' we denote concatenation.
 
 ===Implementation===
 

From e492a90fec53ceb1839080024cc90a41ce503906 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Mon, 18 Dec 2023 20:28:22 -0500
Subject: [PATCH 25/53] Better reference for OP_CAT removal

---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 334cc2022a..ea2213dd0a 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -64,7 +64,7 @@ The value of MAX_SCRIPT_ELEMENT_SIZE is 520.
 
 ==Notes==
 
-OP_CAT as it existed in the Bitcoin codebase prior to the commit "misc changes" 4bd188cS. Nakamoto, "misc changes", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefL381 which disabled it:
+[OP_CAT as it existed in the Bitcoin codebase](https://github.com/bitcoin/bitcoin/blob/01cd2fdaf3ac6071304ceb80fb7436ac02b1059e/script.cpp#L381-L393) prior to the commit "misc changes" 4bd188cS. Nakamoto, "misc changes", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefR94 which disabled it:
 
 
   // (x1 x2 -- out)

From 785b11e8616cf0a15cb19107c0dba7e2b80ffd53 Mon Sep 17 00:00:00 2001
From: Armin Sabouri 
Date: Fri, 29 Dec 2023 12:14:45 -0500
Subject: [PATCH 26/53] Add backwards compatibility section

---
 bip-???-cat.mediawiki | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index ea2213dd0a..8efe002d7e 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -79,6 +79,9 @@ The value of MAX_SCRIPT_ELEMENT_SIZE is 520.
   }
 

 
+==Backwards Compatibility==
+OP_CAT usage in any Non-SegWitV1 script will continue to trigger the SCRIPT_ERR_DISABLED_OPCODE.
+
 ==References==
 
 

From 82fe9fc3dba07d51533dbce4de4b5eb58ddbed55 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 29 Dec 2023 18:29:00 -0500
Subject: [PATCH 27/53] specify the hex value of the opcode

---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 8efe002d7e..6ae466e8a6 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -13,7 +13,7 @@
 
 ==Abstract==
 
-This BIP reintroduces OP_CAT in the form of a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126.
+This BIP reintroduces OP_CAT in the form of a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (the opcode 0x7e).
 
 When evaluated the OP_CAT instruction:
 # Pops the top two values off the stack,

From ae68ef11cb11d54f670779def60479170e64bc49 Mon Sep 17 00:00:00 2001
From: Armin Sabouri 
Date: Sun, 7 Jan 2024 13:24:04 -0500
Subject: [PATCH 28/53] add clarifying note about the current opcode

And some grammar + spelling cleanup
---
 bip-???-cat.mediawiki | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 6ae466e8a6..59f13802a4 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -14,6 +14,7 @@
 ==Abstract==
 
 This BIP reintroduces OP_CAT in the form of a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (the opcode 0x7e).
+Note that the currently disabled opcode also uses `0x7e` in a non-tapscript context and will continue to be disabled.
 
 When evaluated the OP_CAT instruction:
 # Pops the top two values off the stack,
@@ -25,21 +26,21 @@ OP_CAT fails if there are less than two values on the stack or if a concatenated
 ==Motivation==
 Bitcoin tapscript lacks a general purpose way of combining objects on the stack restricting the expressiveness and power of tapscript. This prevents among many other things the ability to construct and evaluate merkle trees and other hashed data structures in tapscript. OP_CAT by adding a general purpose way to concatenate stack values would overcome this limitation and greatly increase the functionality of tapscript.
 
-OP_CAT aims to expands the toolbox of the tapscript developer with a simple, modular and useful opcode in the spirit of Unix R. Pike and B. Kernighan, "Program design in the UNIX environment", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable:
+OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modular, and useful opcode in the spirit of Unix R. Pike and B. Kernighan, "Program design in the UNIX environment", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable:
 
 * Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf
 * Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
 * Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It is an open question if the quantum resistance of Lamport signatures can be preserved when used in a taproot output.
 * Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
-* Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficent to build vaults in Bitcoin.
+* Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficient to build vaults in Bitcoin.
 * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.
 
-The opcode OP_CAT was available in early versions of Bitcoin. However OP_CAT was removed because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script.
+The opcode OP_CAT was available in early versions of Bitcoin. However, OP_CAT was removed because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script.
 For example, a script that pushed a 1-byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack value whose size was greater than 1 terabyte. This is no longer an issue because tapscript enforces a maximum stack element size of 520 bytes.
 
 ==Specification==
 
-OP_CAT pops two elements off the stack, concatenates them together in stack order and pushes the resulting element onto the stack. Given the stack ''[x1, x2]'', where ''x2'' is at the top of the stack, OP_CAT will push ''x1 || x2'' onto the stack. By ''||'' we denote concatenation.
+OP_CAT pops two elements off the stack, concatenates them together in stack order, and pushes the resulting element onto the stack. Given the stack ''[x1, x2]'', where ''x2'' is at the top of the stack, OP_CAT will push ''x1 || x2'' onto the stack. By ''||'' we denote concatenation.
 
 ===Implementation===
 

From f9e100e9de0091be99d06b196a189733e9fe353d Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Sun, 7 Jan 2024 16:34:23 -0500
Subject: [PATCH 29/53] Notes that the opcode used is the same as the original
 cat opcode

---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 6ae466e8a6..ae73ed5813 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -13,7 +13,7 @@
 
 ==Abstract==
 
-This BIP reintroduces OP_CAT in the form of a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (the opcode 0x7e).
+This BIP reintroduces OP_CAT in the form of a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexidecimal). This is same opcode value used by the original OP_CAT.
 
 When evaluated the OP_CAT instruction:
 # Pops the top two values off the stack,

From 2cec73a5b437cc4e3c108cb482de09b0e87edb8d Mon Sep 17 00:00:00 2001
From: Armin Sabouri 
Date: Sun, 7 Jan 2024 18:18:09 -0500
Subject: [PATCH 30/53] rm comment on disabled CAT opcode

---
 bip-???-cat.mediawiki | 1 -
 1 file changed, 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 59f13802a4..7b214d63ce 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -14,7 +14,6 @@
 ==Abstract==
 
 This BIP reintroduces OP_CAT in the form of a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (the opcode 0x7e).
-Note that the currently disabled opcode also uses `0x7e` in a non-tapscript context and will continue to be disabled.
 
 When evaluated the OP_CAT instruction:
 # Pops the top two values off the stack,

From 5dde7ea5cfe2b046dde7f9e7ecf40730f2005697 Mon Sep 17 00:00:00 2001
From: Armin Sabouri 
Date: Sun, 7 Jan 2024 18:18:46 -0500
Subject: [PATCH 31/53] revert changes to abstract

---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 7b214d63ce..4875820a46 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -13,7 +13,7 @@
 
 ==Abstract==
 
-This BIP reintroduces OP_CAT in the form of a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (the opcode 0x7e).
+This BIP reintroduces OP_CAT in the form of a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexidecimal). This is same opcode value used by the original OP_CAT.
 
 When evaluated the OP_CAT instruction:
 # Pops the top two values off the stack,

From b3493746b1a1208ddaae52682f98cdfff1e2d563 Mon Sep 17 00:00:00 2001
From: Armin Sabouri 
Date: Wed, 20 Mar 2024 18:33:02 -0400
Subject: [PATCH 32/53] update OP_CAT implementation

---
 bip-???-cat.mediawiki | 21 +++++++++------------
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 4875820a46..111519d63d 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -43,18 +43,15 @@ OP_CAT pops two elements off the stack, concatenates them together in stack orde
 
 ===Implementation===
 
-case OP_CAT:
-{
-    if (stack.size() < 2) {
-        return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
-    }
-    valtype& vch1 = stacktop(-2);
-    valtype& vch2 = stacktop(-1);
-    if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE) {
-        return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
-    }
-    vch1.insert(vch1.end(), vch2.begin(), vch2.end());
-    stack.pop_back();
+case OP_CAT: {
+  if (stack.size() < 2)
+    return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
+  valtype& vch1 = stacktop(-2);
+  valtype& vch2 = stacktop(-1);
+  if (vch1.size() + vch2.size() > MAX_SCRIPT_ELEMENT_SIZE)
+    return set_error(serror, SCRIPT_ERR_PUSH_SIZE);
+  vch1.insert(vch1.end(), vch2.begin(), vch2.end());
+  stack.pop_back();
 }
 break;
 


From ac231a17c2e6839d9af6576d9aa1c79fb8c16eca Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Wed, 20 Mar 2024 23:53:53 -0400
Subject: [PATCH 33/53] Fixes broken mediawiki link

---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 111519d63d..1f803ba5c4 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -61,7 +61,7 @@ The value of MAX_SCRIPT_ELEMENT_SIZE is 520.
 
 ==Notes==
 
-[OP_CAT as it existed in the Bitcoin codebase](https://github.com/bitcoin/bitcoin/blob/01cd2fdaf3ac6071304ceb80fb7436ac02b1059e/script.cpp#L381-L393) prior to the commit "misc changes" 4bd188cS. Nakamoto, "misc changes", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefR94 which disabled it:
+[https://github.com/bitcoin/bitcoin/blob/01cd2fdaf3ac6071304ceb80fb7436ac02b1059e/script.cpp#L381-L393 OP_CAT as it existed in the Bitcoin codebase] prior to the commit "misc changes" 4bd188cS. Nakamoto, "misc changes", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefR94 which disabled it:
 
 
   // (x1 x2 -- out)

From c235aa493933dfff82ef3ba46a5e56eecb80d3c6 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Tue, 26 Mar 2024 20:36:19 -0400
Subject: [PATCH 34/53] Adds more acknowledgements

---
 bip-???-cat.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 1f803ba5c4..3d3b73444f 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -85,7 +85,7 @@ OP_CAT usage in any Non-SegWitV1 script will continue to trigger the SCRIPT_ERR_
 
 ==Acknowledgements==
 
-We wish to acknowledge Dan Gould for encouraging and helping review this effort. 
+We wish to acknowledge Dan Gould for encouraging and helping review this effort. We also want to thank Madars Virza, Jeremy Rubin, Andrew Poelstra, Bob Summerwill for their feedback and helpful comments.
 
 == Copyright ==
 This document is licensed under the 3-clause BSD license.

From f8ad6ede5753b51bfd8a782f7de6d74a7e06cd95 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 12 Apr 2024 08:48:54 -0400
Subject: [PATCH 35/53] Changes OP_CAT BIP based on feedback given by Bob
 Summerwill

Bob Summerwill proposed a number of changes to the OP_CAT BIP to better follow BIP-2. This commit makes these changes:

* Using the section order specified in BIP-2
* Adding a Rationale section
* Expand the specification section by moving details from the abstract into the specification

Additionally this commit as rewords some confusing language.

Thanks Bob
---
 bip-???-cat.mediawiki | 72 ++++++++++++++++++++++++++-----------------
 1 file changed, 43 insertions(+), 29 deletions(-)

diff --git a/bip-???-cat.mediawiki b/bip-???-cat.mediawiki
index 3d3b73444f..d7746fe4c0 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-???-cat.mediawiki
@@ -1,26 +1,33 @@
 
-  BIP: ???
+  BIP: ?
   Layer: Consensus (soft fork)
   Title: OP_CAT
   Author: Ethan Heilman 
           Armin Sabouri 
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-op-cat
   Status: Draft
   Type: Standards Track
   Created: 2023-10-21
-  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-op-cat
   License: BSD-3-Clause
 

 
 ==Abstract==
 
-This BIP reintroduces OP_CAT in the form of a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexidecimal). This is same opcode value used by the original OP_CAT.
+This BIP introduces OP_CAT as a tapscript opcode which allows the concatenation of two values on the stack. OP_CAT would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexadecimal). This is the same opcode value used by the original OP_CAT.
+
+== Copyright ==
+This document is licensed under the 3-clause BSD license.
+
+==Specification==
 
 When evaluated the OP_CAT instruction:
 # Pops the top two values off the stack,
-# concatenates the popped values together,
+# concatenates the popped values together in stack order,
 # and then pushes the concatenated value on the top of the stack.
 
-OP_CAT fails if there are less than two values on the stack or if a concatenated value would have a combined size greater than the maximum script element size of 520 bytes.
+Given the stack ''[x1, x2]'', where ''x2'' is at the top of the stack, OP_CAT will push ''x1 || x2'' onto the stack. By ''||'' we denote concatenation. OP_CAT fails if there are fewer than two values on the stack or if a concatenated value would have a combined size greater than the maximum script element size of 520 bytes.
+
+This opcode would be activated via a soft fork by redefining the tapscript opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexadecimal) to OP_CAT.
 
 ==Motivation==
 Bitcoin tapscript lacks a general purpose way of combining objects on the stack restricting the expressiveness and power of tapscript. This prevents among many other things the ability to construct and evaluate merkle trees and other hashed data structures in tapscript. OP_CAT by adding a general purpose way to concatenate stack values would overcome this limitation and greatly increase the functionality of tapscript.
@@ -37,13 +44,23 @@ OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modu
 The opcode OP_CAT was available in early versions of Bitcoin. However, OP_CAT was removed because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script.
 For example, a script that pushed a 1-byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack value whose size was greater than 1 terabyte. This is no longer an issue because tapscript enforces a maximum stack element size of 520 bytes.
 
-==Specification==
+==Rationale==
+
+Our decision to reenable OP_CAT by redefining a tapscript OP_SUCCESSx opcode to OP_CAT was motivated to leverage the tapscript softfork opcode upgrade path introduced in [[bip-0342.mediawiki|BIP342]].
+
+We specifically choose to use OP_SUCCESS126 rather than another OP_SUCCESSx as OP_SUCCESS126 uses the same opcode value (126 in decimal and 0x7e in hexadecimal) that was used for OP_CAT prior to it being disabled in Bitcoin. This removes a potential source of confusion that would exist if we had a opcode value different from the one used in the original OP_CAT opcode.
+
+While the OP_SUCCESSx opcode upgrade path could enable us to increase the stack element size while reenabling OP_CAT, we wanted to separate the decision to change the stack element size limit from the decision to reenable OP_CAT. This BIP takes no position in favor or against increasing the stack element size limit.
+
+==Backwards Compatibility==
 
-OP_CAT pops two elements off the stack, concatenates them together in stack order, and pushes the resulting element onto the stack. Given the stack ''[x1, x2]'', where ''x2'' is at the top of the stack, OP_CAT will push ''x1 || x2'' onto the stack. By ''||'' we denote concatenation.
+OP_CAT usage in an non-tapscript script will continue to trigger the SCRIPT_ERR_DISABLED_OPCODE. The only change would be to OP_CAT usage in tapscript. This change to tapscript would be activated a soft fork that redefines an OP_SUCCESSx opcode (OP_SUCCESS126) to OP_CAT.
+
+==Reference implementation==
 
-===Implementation===
 
-case OP_CAT: {
+case OP_CAT:
+{
   if (stack.size() < 2)
     return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
   valtype& vch1 = stacktop(-2);
@@ -55,29 +72,29 @@ case OP_CAT: {
 }
 break;
 

-This implementation is inspired by the original implementation of OP_CAT as shown below. An alternative implementation of OP_CAT can be found in Elements Roose S., Elements Project, "Re-enable several disabled opcodes", 2019, https://github.com/ElementsProject/elements/commit/13e1103abe3e328c5a4e2039b51a546f8be6c60a#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R740-R759.
 
-The value of MAX_SCRIPT_ELEMENT_SIZE is 520.
 
-==Notes==
+The value of MAX_SCRIPT_ELEMENT_SIZE is 520.
 
-[https://github.com/bitcoin/bitcoin/blob/01cd2fdaf3ac6071304ceb80fb7436ac02b1059e/script.cpp#L381-L393 OP_CAT as it existed in the Bitcoin codebase] prior to the commit "misc changes" 4bd188cS. Nakamoto, "misc changes", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefR94 which disabled it:
+This implementation is inspired by the original implementation of [https://github.com/bitcoin/bitcoin/blob/01cd2fdaf3ac6071304ceb80fb7436ac02b1059e/script.cpp#L381-L393 OP_CAT as it existed in the Bitcoin codebase] prior to the commit "misc changes" 4bd188cS. Nakamoto, "misc changes", Aug 25 2010, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefR94 which disabled it:
 
 
-  // (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;
-  }
+case OP_CAT:
+{
+    // (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;
+}
+break;
 

 
-==Backwards Compatibility==
-OP_CAT usage in any Non-SegWitV1 script will continue to trigger the SCRIPT_ERR_DISABLED_OPCODE.
+An alternative implementation of OP_CAT can be found in Elements Roose S., Elements Project, "Re-enable several disabled opcodes", 2019, https://github.com/ElementsProject/elements/commit/13e1103abe3e328c5a4e2039b51a546f8be6c60a#diff-a0337ffd7259e8c7c9a7786d6dbd420c80abfa1afdb34ebae3261109d9ae3c19R740-R759.
 
 ==References==
 
@@ -85,7 +102,4 @@ OP_CAT usage in any Non-SegWitV1 script will continue to trigger the SCRIPT_ERR_
 
 ==Acknowledgements==
 
-We wish to acknowledge Dan Gould for encouraging and helping review this effort. We also want to thank Madars Virza, Jeremy Rubin, Andrew Poelstra, Bob Summerwill for their feedback and helpful comments.
-
-== Copyright ==
-This document is licensed under the 3-clause BSD license.
+We wish to acknowledge Dan Gould for encouraging and helping review this effort. We also want to thank Madars Virza, Jeremy Rubin, Andrew Poelstra, Bob Summerwill for their feedback, review and helpful comments.

From 6c729c4b418006def78caad0d921f1841c4db1ee Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 25 Apr 2024 13:03:00 -0400
Subject: [PATCH 36/53] Renamed to use BIP-0347

---
 bip-???-cat.mediawiki => bip-0347.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename bip-???-cat.mediawiki => bip-0347.mediawiki (99%)

diff --git a/bip-???-cat.mediawiki b/bip-0347.mediawiki
similarity index 99%
rename from bip-???-cat.mediawiki
rename to bip-0347.mediawiki
index d7746fe4c0..f85b2e9f34 100644
--- a/bip-???-cat.mediawiki
+++ b/bip-0347.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: ?
+  BIP: 347
   Layer: Consensus (soft fork)
   Title: OP_CAT
   Author: Ethan Heilman 

From 0a3869d1021bfc0e4c5e8779d1ff33fe67846af8 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 25 Apr 2024 13:16:55 -0400
Subject: [PATCH 37/53] Fixes comment URI

---
 bip-0347.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index f85b2e9f34..a05c2100e8 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -4,7 +4,7 @@
   Title: OP_CAT
   Author: Ethan Heilman 
           Armin Sabouri 
-  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-op-cat
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0347
   Status: Draft
   Type: Standards Track
   Created: 2023-10-21

From 7ed8f6f38c67ede30e38114632b3fa6bbe396800 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 25 Apr 2024 13:42:24 -0400
Subject: [PATCH 38/53] Better quantum resistant section based Tim's comments

Adds additional acks
---
 bip-0347.mediawiki | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index a05c2100e8..1e75ffc144 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -36,7 +36,7 @@ OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modu
 
 * Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf
 * Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
-* Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It is an open question if the quantum resistance of Lamport signatures can be preserved when used in a taproot output.
+* Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It is an open question if a tapscript commitment would preserve the quantum resistance of Lamport signatures. Beyond this question, the use of Lamport Signatures in taproot outputs is unlikely to be quantum resistant even if the script spend-path is made quantum resistant. This is because taproot outputs can also be spent with a key. An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path. The use of "Nothing Up My Sleeve" (NUMS) points as described in [[bip-0341.mediawiki|BIP341]] to disable the key spend-path does not disable the key spend-path against a quantum attacker as NUMS relies on the hardness of finding discrete logs. We are not aware of any mechanism which could disable the key spend-path in a taproot output without a softfork change to taproot.
 * Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
 * Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficient to build vaults in Bitcoin.
 * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.
@@ -102,4 +102,5 @@ An alternative implementation of OP_CAT can be found in Elements Roose S.,
 
 ==Acknowledgements==
 
-We wish to acknowledge Dan Gould for encouraging and helping review this effort. We also want to thank Madars Virza, Jeremy Rubin, Andrew Poelstra, Bob Summerwill for their feedback, review and helpful comments.
+We wish to acknowledge Dan Gould for encouraging and helping review this effort. We also want to thank Madars Virza, Jeremy Rubin, Andrew Poelstra, Bob Summerwill, 
+Tim Ruffing and Johan T. Halseth for their feedback, review and helpful comments.

From 852502b9cf0568dc4c75d93aaaaee3d102002ec7 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 25 Apr 2024 20:32:52 -0400
Subject: [PATCH 39/53] Specifies exact tree signature limit (suggested by Ali
 Sherief)

---
 bip-0347.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index 1e75ffc144..e43bd72f0f 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -35,7 +35,7 @@ Bitcoin tapscript lacks a general purpose way of combining objects on the stack
 OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modular, and useful opcode in the spirit of Unix R. Pike and B. Kernighan, "Program design in the UNIX environment", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable:
 
 * Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf
-* Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
+* Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with up to 4,294,967,296 public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
 * Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It is an open question if a tapscript commitment would preserve the quantum resistance of Lamport signatures. Beyond this question, the use of Lamport Signatures in taproot outputs is unlikely to be quantum resistant even if the script spend-path is made quantum resistant. This is because taproot outputs can also be spent with a key. An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path. The use of "Nothing Up My Sleeve" (NUMS) points as described in [[bip-0341.mediawiki|BIP341]] to disable the key spend-path does not disable the key spend-path against a quantum attacker as NUMS relies on the hardness of finding discrete logs. We are not aware of any mechanism which could disable the key spend-path in a taproot output without a softfork change to taproot.
 * Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
 * Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficient to build vaults in Bitcoin.

From c10870a390a7141eb223ed8141cab48668239536 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 26 Apr 2024 13:59:28 -0400
Subject: [PATCH 40/53] Adds comma

Co-authored-by: Mark "Murch" Erhardt 
---
 bip-0347.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index e43bd72f0f..24df645625 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -20,7 +20,7 @@ This document is licensed under the 3-clause BSD license.
 
 ==Specification==
 
-When evaluated the OP_CAT instruction:
+When evaluated, the OP_CAT instruction:
 # Pops the top two values off the stack,
 # concatenates the popped values together in stack order,
 # and then pushes the concatenated value on the top of the stack.

From 5413e18fd93c078d4c12d4845a08b7c9a9b24ada Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 26 Apr 2024 14:01:59 -0400
Subject: [PATCH 41/53] Consistent formatting for Section Headings

Co-authored-by: Mark "Murch" Erhardt 
---
 bip-0347.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index 24df645625..dca210006d 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -30,6 +30,7 @@ Given the stack ''[x1, x2]'', where ''x2'' is at the top of the
 This opcode would be activated via a soft fork by redefining the tapscript opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexadecimal) to OP_CAT.
 
 ==Motivation==
+
 Bitcoin tapscript lacks a general purpose way of combining objects on the stack restricting the expressiveness and power of tapscript. This prevents among many other things the ability to construct and evaluate merkle trees and other hashed data structures in tapscript. OP_CAT by adding a general purpose way to concatenate stack values would overcome this limitation and greatly increase the functionality of tapscript.
 
 OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modular, and useful opcode in the spirit of Unix R. Pike and B. Kernighan, "Program design in the UNIX environment", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable:

From dbc612edfa137ce1f1cbcb9d40f58773758315ae Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Fri, 26 Apr 2024 14:02:13 -0400
Subject: [PATCH 42/53] Consistent formatting for Section Headings

Co-authored-by: Mark "Murch" Erhardt 
---
 bip-0347.mediawiki | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index dca210006d..e825284c22 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -16,6 +16,7 @@
 This BIP introduces OP_CAT as a tapscript opcode which allows the concatenation of two values on the stack. OP_CAT would be activated via a soft fork by redefining the opcode OP_SUCCESS126 (126 in decimal and 0x7e in hexadecimal). This is the same opcode value used by the original OP_CAT.
 
 == Copyright ==
+
 This document is licensed under the 3-clause BSD license.
 
 ==Specification==

From a05543cc588ebcb266aa3251472324671e384afe Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Mon, 29 Apr 2024 18:44:24 -0400
Subject: [PATCH 43/53] Changes title of BIP to "Enable OP_CAT in Tapscript"

---
 bip-0347.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index e825284c22..1a0feb8896 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: 347
   Layer: Consensus (soft fork)
-  Title: OP_CAT
+  Title: Enable OP_CAT in Tapscript
   Author: Ethan Heilman 
           Armin Sabouri 
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0347

From 1d5530443dd660dc090145061bc146d4c64ffab3 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Mon, 29 Apr 2024 19:36:26 -0400
Subject: [PATCH 44/53] OP_CAT in Tapscript
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>
---
 bip-0347.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index 1a0feb8896..3070d14e48 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: 347
   Layer: Consensus (soft fork)
-  Title: Enable OP_CAT in Tapscript
+  Title: OP_CAT in Tapscript
   Author: Ethan Heilman 
           Armin Sabouri 
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0347

From 3d78cc08863864d7caea85a229fb223dea25540f Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Mon, 29 Apr 2024 21:04:15 -0400
Subject: [PATCH 45/53] Fixes typos

Co-authored-by: Mark "Murch" Erhardt 
---
 bip-0347.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index 3070d14e48..622d7b46ec 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -56,7 +56,7 @@ While the OP_SUCCESSx opcode upgrade path could enable us to increase the stack
 
 ==Backwards Compatibility==
 
-OP_CAT usage in an non-tapscript script will continue to trigger the SCRIPT_ERR_DISABLED_OPCODE. The only change would be to OP_CAT usage in tapscript. This change to tapscript would be activated a soft fork that redefines an OP_SUCCESSx opcode (OP_SUCCESS126) to OP_CAT.
+OP_CAT usage in a non-tapscript script will continue to trigger the SCRIPT_ERR_DISABLED_OPCODE. The only change would be to OP_CAT usage in tapscript. This change to tapscript would be activated as a soft fork that redefines an OP_SUCCESSx opcode (OP_SUCCESS126) to OP_CAT.
 
 ==Reference implementation==
 

From 696cc1713b931589d01c544d3016f3cf57be0058 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Tue, 30 Apr 2024 21:13:43 -0400
Subject: [PATCH 46/53] Adds post history, fixes created date

---
 bip-0347.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index 622d7b46ec..88dad57ae9 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -7,8 +7,9 @@
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0347
   Status: Draft
   Type: Standards Track
-  Created: 2023-10-21
+  Created: 2023-12-11
   License: BSD-3-Clause
+  Post-History: 2023-10-21: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022049.html [bitcoin-dev] Proposed BIP for OP_CAT
 

 
 ==Abstract==

From d670035b0c0ef60c10e9e818f3fbf6f11779257f Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Wed, 1 May 2024 16:30:38 -0400
Subject: [PATCH 47/53] Adds sentence suggested by murchandamus to quantum
 paragraph

Co-authored-by: Mark "Murch" Erhardt 
---
 bip-0347.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index 88dad57ae9..29d9219e97 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -39,7 +39,7 @@ OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modu
 
 * Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf
 * Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with up to 4,294,967,296 public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
-* Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It is an open question if a tapscript commitment would preserve the quantum resistance of Lamport signatures. Beyond this question, the use of Lamport Signatures in taproot outputs is unlikely to be quantum resistant even if the script spend-path is made quantum resistant. This is because taproot outputs can also be spent with a key. An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path. The use of "Nothing Up My Sleeve" (NUMS) points as described in [[bip-0341.mediawiki|BIP341]] to disable the key spend-path does not disable the key spend-path against a quantum attacker as NUMS relies on the hardness of finding discrete logs. We are not aware of any mechanism which could disable the key spend-path in a taproot output without a softfork change to taproot.
+* Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It has been proposed that if ECDSA is broken or a powerful computer was on the horizon, there might be an effort to protect ownership of bitcoins by allowing people to mark their taproot outputs as "script-path only" and then move their coins into such outputs with a leaf in the script tree requiring a Lamport signature. It is an open question if a tapscript commitment would preserve the quantum resistance of Lamport signatures. Beyond this question, the use of Lamport Signatures in taproot outputs is unlikely to be quantum resistant even if the script spend-path is made quantum resistant. This is because taproot outputs can also be spent with a key. An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path. The use of "Nothing Up My Sleeve" (NUMS) points as described in [[bip-0341.mediawiki|BIP341]] to disable the key spend-path does not disable the key spend-path against a quantum attacker as NUMS relies on the hardness of finding discrete logs. We are not aware of any mechanism which could disable the key spend-path in a taproot output without a softfork change to taproot.
 * Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
 * Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficient to build vaults in Bitcoin.
 * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.

From e9e7636f7e7d5454c2993394518b48f6b4f0833a Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Wed, 1 May 2024 16:31:49 -0400
Subject: [PATCH 48/53] Increases commas and capital letters

This improves readability, thanks!

Co-authored-by: Mark "Murch" Erhardt 
---
 bip-0347.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index 29d9219e97..2d4ab05ebc 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -33,7 +33,7 @@ This opcode would be activated via a soft fork by redefining the tapscript opcod
 
 ==Motivation==
 
-Bitcoin tapscript lacks a general purpose way of combining objects on the stack restricting the expressiveness and power of tapscript. This prevents among many other things the ability to construct and evaluate merkle trees and other hashed data structures in tapscript. OP_CAT by adding a general purpose way to concatenate stack values would overcome this limitation and greatly increase the functionality of tapscript.
+Bitcoin Tapscript lacks a general purpose way of combining objects on the stack, restricting the expressiveness and power of Tapscript. This prevents, among many other things, the ability to construct and evaluate merkle trees and other hashed data structures in Tapscript. OP_CAT, by adding a general purpose way to concatenate stack values, would overcome this limitation and greatly increase the functionality of Tapscript.
 
 OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modular, and useful opcode in the spirit of Unix R. Pike and B. Kernighan, "Program design in the UNIX environment", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable:
 

From 6815c39f93a7f26f509fb4e3dedf4c0d654ae857 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Wed, 1 May 2024 16:32:28 -0400
Subject: [PATCH 49/53] Adds commas

Co-authored-by: Mark "Murch" Erhardt 
---
 bip-0347.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index 2d4ab05ebc..8d7bf32e2d 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -37,7 +37,7 @@ Bitcoin Tapscript lacks a general purpose way of combining objects on the stack,
 
 OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modular, and useful opcode in the spirit of Unix R. Pike and B. Kernighan, "Program design in the UNIX environment", 1983, https://harmful.cat-v.org/cat-v/unix_prog_design.pdf. To demonstrate the usefulness of OP_CAT below we provide a non-exhaustive list of some usecases that OP_CAT would enable:
 
-* Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf
+* Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT, they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf
 * Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with up to 4,294,967,296 public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
 * Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It has been proposed that if ECDSA is broken or a powerful computer was on the horizon, there might be an effort to protect ownership of bitcoins by allowing people to mark their taproot outputs as "script-path only" and then move their coins into such outputs with a leaf in the script tree requiring a Lamport signature. It is an open question if a tapscript commitment would preserve the quantum resistance of Lamport signatures. Beyond this question, the use of Lamport Signatures in taproot outputs is unlikely to be quantum resistant even if the script spend-path is made quantum resistant. This is because taproot outputs can also be spent with a key. An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path. The use of "Nothing Up My Sleeve" (NUMS) points as described in [[bip-0341.mediawiki|BIP341]] to disable the key spend-path does not disable the key spend-path against a quantum attacker as NUMS relies on the hardness of finding discrete logs. We are not aware of any mechanism which could disable the key spend-path in a taproot output without a softfork change to taproot.
 * Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.

From 6ea9fda9aca437778d8162f6dbf80d7a5aca6b99 Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Thu, 2 May 2024 18:39:58 -0400
Subject: [PATCH 50/53] Fixes link to liar liar

---
 bip-0347.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index 8d7bf32e2d..0e198958e1 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -40,7 +40,7 @@ OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modu
 * Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT, they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf
 * Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with up to 4,294,967,296 public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
 * Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It has been proposed that if ECDSA is broken or a powerful computer was on the horizon, there might be an effort to protect ownership of bitcoins by allowing people to mark their taproot outputs as "script-path only" and then move their coins into such outputs with a leaf in the script tree requiring a Lamport signature. It is an open question if a tapscript commitment would preserve the quantum resistance of Lamport signatures. Beyond this question, the use of Lamport Signatures in taproot outputs is unlikely to be quantum resistant even if the script spend-path is made quantum resistant. This is because taproot outputs can also be spent with a key. An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path. The use of "Nothing Up My Sleeve" (NUMS) points as described in [[bip-0341.mediawiki|BIP341]] to disable the key spend-path does not disable the key spend-path against a quantum attacker as NUMS relies on the hardness of finding discrete logs. We are not aware of any mechanism which could disable the key spend-path in a taproot output without a softfork change to taproot.
-* Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
+* Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://dl.acm.org/doi/10.1145/2810103.2813686 in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
 * Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficient to build vaults in Bitcoin.
 * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.
 

From 31f51927f12906678e9e710c2871eccc0fc2dd40 Mon Sep 17 00:00:00 2001
From: Murch 
Date: Thu, 2 May 2024 21:57:31 -0400
Subject: [PATCH 51/53] Add BIP-347 OP_CAT to table

---
 README.mediawiki | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/README.mediawiki b/README.mediawiki
index 96b8df3372..ed7df0c9de 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -1072,6 +1072,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Standard
 | Final
 |-
+| [[bip-0347.mediawiki|347]]
+| Consensus (soft fork)
+| OP_CAT in Tapscript
+| Ethan Heilman, Armin Sabouri
+| Standard
+| Draft
+|-
 | [[bip-0350.mediawiki|350]]
 | Applications
 | Bech32m format for v1+ witness addresses

From cda34eef1c2543ece1205240f27e8d1cfffb336d Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Sun, 5 May 2024 17:57:27 -0400
Subject: [PATCH 52/53] Improved accuracy of paragraph on OP_CAT's removal in
 2010

---
 bip-0347.mediawiki | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index 0e198958e1..545ffbb6fa 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -44,8 +44,12 @@ OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modu
 * Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficient to build vaults in Bitcoin.
 * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.
 
-The opcode OP_CAT was available in early versions of Bitcoin. However, OP_CAT was removed because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script.
-For example, a script that pushed a 1-byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack value whose size was greater than 1 terabyte. This is no longer an issue because tapscript enforces a maximum stack element size of 520 bytes.
+OP_CAT was available in early versions of Bitcoin. 
+In 2010, a single commit disabled OP_CAT, along with another 15 opcodes.
+Folklore states that OP_CAT was removed in this commit because it enabled the construction of a script whose evaluation could have memory usage exponential in the size of the script.
+For example, a script that pushed a 1-byte value on the stack and then repeated the opcodes OP_DUP, OP_CAT 40 times would result in a stack element whose size was greater than 1 terabyte assuming no maximum stack element size. As Bitcoin at that time had a maximum stack element size of 5000 bytes, the effect of this expansion was limited to 5000 bytes.
+This is no longer an issue because tapscript enforces a maximum stack element size of 520 bytes.
+
 
 ==Rationale==
 

From 7ad0f821ddc60366e98344a1e3019114ae46c80f Mon Sep 17 00:00:00 2001
From: Ethan Heilman 
Date: Mon, 6 May 2024 13:12:47 -0400
Subject: [PATCH 53/53] Adds stable URL for Liar, Liar, Coins on Fire!

---
 bip-0347.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0347.mediawiki b/bip-0347.mediawiki
index 545ffbb6fa..981af8127b 100644
--- a/bip-0347.mediawiki
+++ b/bip-0347.mediawiki
@@ -40,7 +40,7 @@ OP_CAT aims to expand the toolbox of the tapscript developer with a simple, modu
 * Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT, they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf
 * Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with up to 4,294,967,296 public keys. This also enables generalized logical spend conditions.  P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/
 * Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html It has been proposed that if ECDSA is broken or a powerful computer was on the horizon, there might be an effort to protect ownership of bitcoins by allowing people to mark their taproot outputs as "script-path only" and then move their coins into such outputs with a leaf in the script tree requiring a Lamport signature. It is an open question if a tapscript commitment would preserve the quantum resistance of Lamport signatures. Beyond this question, the use of Lamport Signatures in taproot outputs is unlikely to be quantum resistant even if the script spend-path is made quantum resistant. This is because taproot outputs can also be spent with a key. An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path. The use of "Nothing Up My Sleeve" (NUMS) points as described in [[bip-0341.mediawiki|BIP341]] to disable the key spend-path does not disable the key spend-path against a quantum attacker as NUMS relies on the hardness of finding discrete logs. We are not aware of any mechanism which could disable the key spend-path in a taproot output without a softfork change to taproot.
-* Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://dl.acm.org/doi/10.1145/2810103.2813686 in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
+* Non-equivocation contracts T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://web.archive.org/web/20221023121048/https://publications.cispa.saarland/565/1/penalizing.pdf in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols.
 * Vaults M. Moser, I. Eyal, and E. G. Sirer, Bitcoin Covenants, http://fc16.ifca.ai/bitcoin/papers/MES16.pdf which are a specialized covenant that allows a user to block a malicious party who has compromised the user's secret key from stealing the funds in that output. As shown in A. Poelstra, "CAT and Schnorr Tricks II", 2021, https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-ii.html OP_CAT is sufficient to build vaults in Bitcoin.
 * Replicating CheckSigFromStack A. Poelstra, "CAT and Schnorr Tricks I", 2021, https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 which would allow the creation of simple covenants and other advanced contracts without having to presign spending transactions, possibly reducing complexity and the amount of data that needs to be stored. Originally shown to work with Schnorr signatures, this result has been extended to ECDSA signatures R. Linus, "Covenants with CAT and ECDSA", 2023, https://gist.github.com/RobinLinus/9a69f5552be94d13170ec79bf34d5e85#file-covenants_cat_ecdsa-md.