Skip to content

Commit 4ffce31

Browse files
authored
Topics: separate OP_CAT into its own topic page (#1500)
* Topics: separate OP_CAT into its own topic page It was previously a subsection of OP_CSFS
1 parent 0172adc commit 4ffce31

File tree

8 files changed

+128
-14
lines changed

8 files changed

+128
-14
lines changed

_includes/references.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@
33
[compatibility matrix]: /en/compatibility/
44
[topics]: /en/topics/
55
[podcast]: /en/podcast/
6-
[op_cat]: /en/topics/op_checksigfromstack/#relationship-to-op_cat
6+
[op_cat]: /en/topics/op_cat/
77
[optech email]: mailto:[email protected]
88
[rss feed]: /feed.xml
99
[scaling payment batching]: /en/payment-batching/

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

+1-2
Original file line numberDiff line numberDiff line change
@@ -100,7 +100,7 @@ expressed the desire to build on top of taproot.
100100
extended to handle larger numbers.
101101

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

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

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

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

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

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

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

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

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

_topics/en/op_cat.md

+123
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,123 @@
1+
---
2+
title: OP_CAT
3+
4+
## Optional. Shorter name to use for reference style links e.g., "foo"
5+
## will allow using the link [topic foo][]. Not case sensitive
6+
# shortname: foo
7+
8+
## Optional. An entry will be added to the topics index for each alias
9+
#aliases:
10+
# - Foo
11+
12+
## Required. At least one category to which this topic belongs. See
13+
## schema for options
14+
categories:
15+
- Scripts and Addresses
16+
- Soft Forks
17+
18+
## Optional. Produces a Markdown link with either "[title][]" or
19+
## "[title](link)"
20+
primary_sources:
21+
- title: "BIN24-1: `OP_CAT`"
22+
link: https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
23+
24+
## Optional. Each entry requires "title" and "url". May also use "feature:
25+
## true" to bold entry and "date"
26+
optech_mentions:
27+
- title: "Replicating `OP_CHECKSIGFROMSTACK` with schnorr signatures and `OP_CAT`"
28+
url: /en/newsletters/2021/02/03/#replicating-op-checksigfromstack-with-bip340-and-op-cat
29+
30+
- title: "Example of using the MATT proposal plus OP_CAT to manage joinpools"
31+
url: /en/newsletters/2023/06/07/#using-matt-to-replicate-ctv-and-manage-joinpools
32+
33+
- title: "Alternative to COSHV (CTV) and SIGHASH_ANYPREVOUT: OP_CAT and OP_CHECKSIGFROMSTACK"
34+
url: /en/newsletters/2019/05/29/#not-generic-enough
35+
36+
- title: "Discussion about `SIGHASH_ANYPREVOUT` spins off into discussion about `OP_CAT`"
37+
url: /en/newsletters/2019/10/09/#continued-discussion-about-noinput-anyprevout
38+
39+
- title: "Discussion about `OP_CHECKSIGFROMSTACK` branches off into discussion about `OP_CAT`"
40+
url: /en/newsletters/2021/07/14/#request-for-op-checksigfromstack-design-suggestions
41+
42+
- title: "Examination of the minimal set of features added to `OP_CAT` that would create recursive covenants"
43+
url: /en/newsletters/2022/05/18/#when-would-enabling-op-cat-allow-recursive-covenants
44+
45+
- title: "Ark proposal would benefit from `OP_CAT` and `OP_CHECKSIGFROMSTACK`"
46+
url: /en/newsletters/2023/05/31/#proposal-for-a-managed-joinpool-protocol
47+
48+
- title: "Proposed BIP for `OP_CAT`"
49+
url: /en/newsletters/2023/10/25/#proposed-bip-for-op-cat
50+
51+
- title: "Comments on draft BIP for `OP_CAT`"
52+
url: /en/newsletters/2023/11/01/#op-cat-proposal
53+
54+
## Optional. Same format as "primary_sources" above
55+
see_also:
56+
- title: OP_CHECKSIGFROMSTACK
57+
link: topic op_checksigfromstack
58+
59+
- title: OP_CHECKTEMPLATEVERIFY
60+
link: topic op_checktemplateverify
61+
62+
- title: MATT
63+
link: topic matt
64+
65+
## Optional. Force the display (true) or non-display (false) of stub
66+
## topic notice. Default is to display if the page.content is below a
67+
## threshold word count
68+
#stub: false
69+
70+
## Required. Use Markdown formatting. Only one paragraph. No links allowed.
71+
## Should be less than 500 characters
72+
excerpt: >
73+
**OP_CAT** was originally an opcode in Bitcoin. It was disabled in
74+
2010 but slight variations on it are frequently proposed to be
75+
added to Bitcoin using a soft fork.
76+
77+
---
78+
Both the original `OP_CAT` and the new proposals for it
79+
concatenate two elements on the stack into a single element. For
80+
example, the following script:
81+
82+
<0xB10C> <0xCAFE> OP_CAT
83+
84+
Would become:
85+
86+
<0xB10CCAFE>
87+
88+
The primary expected use for `OP_CAT` is for data provided by the
89+
creator of a script to be concatenated with data provided by someone
90+
spending from that script. For example, Alice wants to create an
91+
equivocation bond that she can't create competing spends for without
92+
putting her funds at risk. She generates a private key in the normal
93+
way, derives a public key from it in the normal way, chooses a
94+
random private nonce the same way she usually would for a [schnorr
95+
signature][topic schnorr signatures], and derives the public nonce also
96+
in the normal way. She then pays to the following script:
97+
98+
<public nonce> OP_CAT <pubkey> OP_CHECKSIG
99+
100+
Later, when she signs, instead of providing a complete schnorr
101+
signature---which includes both a public nonce and a scalar---she's
102+
forced to use the public nonce from her script. In her witness field,
103+
she only provides the scalar. The scalar and the public nonce are
104+
concatenated together to produce a [BIP340][] schnorr signature, which
105+
is then verified against Alice's public key like normal using the
106+
`OP_CHECKSIG` opcode.
107+
108+
If Alice later tries to sign a different version of the transaction,
109+
she's forced to reuse the same public nonce but must (because of the
110+
BIP340 equation) generate a different scalar. This reuse of the same
111+
nonce in different signatures from the same private key allows anyone to
112+
derive her private key. They can then create their own signatures for
113+
Alice's private key, potentially spending her funds if they haven't been
114+
spent already.
115+
116+
There are many other proposed applications of `OP_CAT`, see [BIN24-1][]
117+
for one list. Some applications, such as the example above, are
118+
possible with just `OP_CAT` and other features that are already part of
119+
Bitcoin script; other applications require additional new opcodes or
120+
other changes to Bitcoin.
121+
122+
{% include references.md %}
123+
{% include linkers/issues.md issues="" %}

_topics/en/op_checksigfromstack.md

+2-6
Original file line numberDiff line numberDiff line change
@@ -47,9 +47,6 @@ optech_mentions:
4747
- title: "Proposal for `OP_TX` opcode composable with `OP_CHECKSIGFROMSTACK`"
4848
url: /en/newsletters/2022/02/16/#simplified-alternative-to-op-txhash
4949

50-
- title: "Example of using the MATT proposal plus OP_CAT to manage joinpools"
51-
url: /en/newsletters/2023/06/07/#using-matt-to-replicate-ctv-and-manage-joinpools
52-
5350
- title: "Fraud proofs for outdated backup state enforcable onchain with OP_CSFS + OP_CAT"
5451
url: /en/newsletters/2023/08/23/#fraud-proofs-for-outdated-backup-state
5552

@@ -173,15 +170,14 @@ features for Bitcoin users:
173170
### Relationship to OP_CAT
174171

175172
Proposals to add `OP_CSFS` to Bitcoin are often combined with
176-
proposals to restore the `OP_CAT` opcode [removed][dead cat] as part
173+
proposals to restore the [OP_CAT][topic op_cat] opcode [removed][dead cat] as part
177174
of the response to the [value overflow incident][]. This opcode
178175
[catenates][] two elements, appending one to the other. This makes it
179176
possible to construct a message (such as a serialized transaction) by
180177
appending together individual parts of the message (e.g. the fields of
181178
a transaction). Initializing the stack with the message already split
182179
into parts simplifies the writing of scripts that perform tests on
183-
those parts. Beyond the basic risks of adding any new consensus
184-
code to Bitcoin, there are no published downsides of adding `OP_CAT`.
180+
those parts.
185181

186182
{% include references.md %}
187183
[dead cat]: https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-8458adcedc17d046942185cb709ff5c3R94

0 commit comments

Comments
 (0)