Topics: separate OP_CAT into its own topic page

_includes/references.md

@@ -3,7 +3,7 @@
 [compatibility matrix]: /en/compatibility/
 [topics]: /en/topics/
 [podcast]: /en/podcast/
-[op_cat]: /en/topics/op_checksigfromstack/#relationship-to-op_cat
+[op_cat]: /en/topics/op_cat/
 [optech email]: mailto:[email protected]
 [rss feed]: /feed.xml
 [scaling payment batching]: /en/payment-batching/

_includes/specials/taproot/en/19-future.md

@@ -100,7 +100,7 @@ expressed the desire to build on top of taproot.
       extended to handle larger numbers.
 
     - **OP_CAT:** one of the previously-disabled opcodes that deserves
-      special mention is [OP_CAT][op_cat subtopic], which researchers
+      special mention is [OP_CAT][], which researchers
       have since discovered can [enable][keytrees] all [sorts][rubin
       pqc] of [interesting][poelstra cat] behavior on Bitcoin by itself,
       or which can be [combined][topic op_checksigfromstack] with other
@@ -130,7 +130,6 @@ rules.
 [p4tr vaults]: /en/preparing-for-taproot/#vaults-with-taproot
 [rubin delegation]: /en/newsletters/2021/03/24/#signing-delegation-under-existing-consensus-rules
 [p4tr taproot assumption]: /en/preparing-for-taproot/#is-cooperation-always-an-option
-[op_cat subtopic]: /en/topics/op_checksigfromstack/#relationship-to-op_cat
 [keytrees]: https://blockstream.com/2015/08/24/en-treesignatures/#h.2lysjsnoo7jd
 [rubin pqc]: https://rubin.io/blog/2021/07/06/quantum-bitcoin/
 [poelstra cat]: https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html

_posts/en/newsletters/2021-02-03-newsletter.md

@@ -19,7 +19,7 @@ popular Bitcoin infrastructure projects.
   the functionality of the
   [OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (`OP_CSFS`) opcode
   from [ElementsProject.org][] on Bitcoin using the proposed [BIP340][] specification of [schnorr
-  signatures][topic schnorr signatures] and an [OP_CAT][csfs cat] opcode
+  signatures][topic schnorr signatures] and an [OP_CAT][] opcode
   that was part of Bitcoin until mid-2010 (and which is often mentioned
   as a candidate for reintroduction).  Enabling CSFS-like behavior on
   Bitcoin would allow the creation of [covenants][topic covenants] and
@@ -73,6 +73,5 @@ BOLTs][bolts repo].*
 {% include linkers/issues.md issues="16528,20226,163,430,415" %}
 [btcpay server 1.0.6.8]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.0.6.8
 [poelstra 340cat]: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
-[csfs cat]: /en/topics/op_checksigfromstack/#relationship-to-op_cat
 [news96 descriptor wallets]: /en/newsletters/2020/05/06/#bitcoin-core-16528
 [news132 bitcoin core v0.21]: /en/newsletters/2021/01/20/#bitcoin-core-0-21-0

_posts/en/newsletters/2021-07-14-newsletter.md

@@ -223,7 +223,6 @@ BOLTs][bolts repo].*
 [lnd leader]: https://github.com/bhandras/lnd/blob/f41771ce54bb7721101658477ad538991fc99fe6/docs/leader_election.md
 [nick varsig]: https://github.com/bitcoin-core/secp256k1/pull/844/commits/a0c3fc177f7f435e593962504182c3861c47d1be
 [news48 generic csfs]: /en/newsletters/2019/05/29/#not-generic-enough
-[op_cat]: /en/topics/op_checksigfromstack/#relationship-to-op_cat
 [rubin cost/benefit]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019200.html
 [offers spec changes]: https://github.com/lightningnetwork/lightning-rfc/pull/798#issuecomment-871124755
 [suredbits enterprise ln]: /en/suredbits-enterprise-ln/

_posts/en/newsletters/2022-03-09-newsletter.md

@@ -275,7 +275,6 @@ Proposals (BIPs)][bips repo], and [Lightning BOLTs][bolts repo].*
 [news185 optxhash]: /en/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo
 [news187 optx]: /en/newsletters/2022/02/16/#simplified-alternative-to-op-txhash
 [rubin recurse]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019872.html
-[op_cat]: /en/topics/op_checksigfromstack/#relationship-to-op_cat
 [shinobi recurse]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019891.html
 [news157 csfs]: /en/newsletters/2021/07/14/#request-for-op-checksigfromstack-design-suggestions
 [darosior reply]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019892.html

_posts/en/newsletters/2022-05-18-newsletter.md

@@ -592,7 +592,6 @@ Alex Morcos.
 [news136 sms]: /en/newsletters/2021/02/17/#securely-setting-up-multisig-wallets
 [news183 dos]: /en/newsletters/2022/01/19/#mailing-list-discussion
 [zmnscpxj cat1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020434.html
-[op_cat]: /en/topics/op_checksigfromstack/#relationship-to-op_cat
 [news187 op_tx]: /en/newsletters/2022/02/16/#simplified-alternative-to-op-txhash
 [ivgi cat]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020442.html
 [zmnscpxj cat2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020441.html

_topics/en/op_cat.md

@@ -0,0 +1,123 @@
+---
+title: OP_CAT
+
+## Optional.  Shorter name to use for reference style links e.g., "foo"
+## will allow using the link [topic foo][].  Not case sensitive
+# shortname: foo
+
+## Optional.  An entry will be added to the topics index for each alias
+#aliases:
+#  - Foo
+
+## Required.  At least one category to which this topic belongs.  See
+## schema for options
+categories:
+  - Scripts and Addresses
+  - Soft Forks
+
+## Optional.  Produces a Markdown link with either "[title][]" or
+## "[title](link)"
+primary_sources:
+    - title: "BIN24-1: `OP_CAT`"
+      link: https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
+
+## Optional.  Each entry requires "title" and "url".  May also use "feature:
+## true" to bold entry and "date"
+optech_mentions:
+  - title: "Replicating `OP_CHECKSIGFROMSTACK` with schnorr signatures and `OP_CAT`"
+    url: /en/newsletters/2021/02/03/#replicating-op-checksigfromstack-with-bip340-and-op-cat
+
+  - title: "Example of using the MATT proposal plus OP_CAT to manage joinpools"
+    url: /en/newsletters/2023/06/07/#using-matt-to-replicate-ctv-and-manage-joinpools
+
+  - title: "Alternative to COSHV (CTV) and SIGHASH_ANYPREVOUT: OP_CAT and OP_CHECKSIGFROMSTACK"
+    url: /en/newsletters/2019/05/29/#not-generic-enough
+
+  - title: "Discussion about `SIGHASH_ANYPREVOUT` spins off into discussion about `OP_CAT`"
+    url: /en/newsletters/2019/10/09/#continued-discussion-about-noinput-anyprevout
+
+  - title: "Discussion about `OP_CHECKSIGFROMSTACK` branches off into discussion about `OP_CAT`"
+    url: /en/newsletters/2021/07/14/#request-for-op-checksigfromstack-design-suggestions
+
+  - title: "Examination of the minimal set of features added to `OP_CAT` that would create recursive covenants"
+    url: /en/newsletters/2022/05/18/#when-would-enabling-op-cat-allow-recursive-covenants
+
+  - title: "Ark proposal would benefit from `OP_CAT` and `OP_CHECKSIGFROMSTACK`"
+    url: /en/newsletters/2023/05/31/#proposal-for-a-managed-joinpool-protocol
+
+  - title: "Proposed BIP for `OP_CAT`"
+    url: /en/newsletters/2023/10/25/#proposed-bip-for-op-cat
+
+  - title: "Comments on draft BIP for `OP_CAT`"
+    url: /en/newsletters/2023/11/01/#op-cat-proposal
+
+## Optional.  Same format as "primary_sources" above
+see_also:
+  - title: OP_CHECKSIGFROMSTACK
+    link: topic op_checksigfromstack
+
+  - title: OP_CHECKTEMPLATEVERIFY
+    link: topic op_checktemplateverify
+
+  - title: MATT
+    link: topic matt
+
+## Optional.  Force the display (true) or non-display (false) of stub
+## topic notice.  Default is to display if the page.content is below a
+## threshold word count
+#stub: false
+
+## Required.  Use Markdown formatting.  Only one paragraph.  No links allowed.
+## Should be less than 500 characters
+excerpt: >
+  **OP_CAT** was originally an opcode in Bitcoin.  It was disabled in
+  2010 but slight variations on it are frequently proposed to be
+  added to Bitcoin using a soft fork.
+
+---
+Both the original `OP_CAT` and the new proposals for it
+concatenate two elements on the stack into a single element.  For
+example, the following script:
+
+    <0xB10C> <0xCAFE> OP_CAT
+
+Would become:
+
+    <0xB10CCAFE>
+
+The primary expected use for `OP_CAT` is for data provided by the
+creator of a script to be concatenated with data provided by someone
+spending from that script.  For example, Alice wants to create an
+equivocation bond that she can't create competing spends for without
+putting her funds at risk.  She generates a private key in the normal
+way, derives a public key from it in the normal way, chooses a
+random private nonce the same way she usually would for a [schnorr
+signature][topic schnorr signatures], and derives the public nonce also
+in the normal way.  She then pays to the following script:
+
+    <public nonce> OP_CAT <pubkey> OP_CHECKSIG
+
+Later, when she signs, instead of providing a complete schnorr
+signature---which includes both a public nonce and a scalar---she's
+forced to use the public nonce from her script.  In her witness field,
+she only provides the scalar.  The scalar and the public nonce are
+concatenated together to produce a [BIP340][] schnorr signature, which
+is then verified against Alice's public key like normal using the
+`OP_CHECKSIG` opcode.
+
+If Alice later tries to sign a different version of the transaction,
+she's forced to reuse the same public nonce but must (because of the
+BIP340 equation) generate a different scalar.  This reuse of the same
+nonce in different signatures from the same private key allows anyone to
+derive her private key.  They can then create their own signatures for
+Alice's private key, potentially spending her funds if they haven't been
+spent already.
+
+There are many other proposed applications of `OP_CAT`, see [BIN24-1][]
+for one list.  Some applications, such as the example above, are
+possible with just `OP_CAT` and other features that are already part of
+Bitcoin script; other applications require additional new opcodes or
+other changes to Bitcoin.
+
+{% include references.md %}
+{% include linkers/issues.md issues="" %}

_topics/en/op_checksigfromstack.md

@@ -47,9 +47,6 @@ optech_mentions:
   - title: "Proposal for `OP_TX` opcode composable with `OP_CHECKSIGFROMSTACK`"
     url: /en/newsletters/2022/02/16/#simplified-alternative-to-op-txhash
 
-  - title: "Example of using the MATT proposal plus OP_CAT to manage joinpools"
-    url: /en/newsletters/2023/06/07/#using-matt-to-replicate-ctv-and-manage-joinpools
-
   - title: "Fraud proofs for outdated backup state enforcable onchain with OP_CSFS + OP_CAT"
     url: /en/newsletters/2023/08/23/#fraud-proofs-for-outdated-backup-state
 
@@ -173,15 +170,14 @@ features for Bitcoin users:
 ### Relationship to OP_CAT
 
 Proposals to add `OP_CSFS` to Bitcoin are often combined with
-proposals to restore the `OP_CAT` opcode [removed][dead cat] as part
+proposals to restore the [OP_CAT][topic op_cat] opcode [removed][dead cat] as part
 of the response to the [value overflow incident][].  This opcode
 [catenates][] two elements, appending one to the other.  This makes it
 possible to construct a message (such as a serialized transaction) by
 appending together individual parts of the message (e.g. the fields of
 a transaction).  Initializing the stack with the message already split
 into parts simplifies the writing of scripts that perform tests on
-those parts.  Beyond the basic risks of adding any new consensus
-code to Bitcoin, there are no published downsides of adding `OP_CAT`.
+those parts.
 
 {% include references.md %}
 [dead cat]: https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-8458adcedc17d046942185cb709ff5c3R94