diff --git a/_includes/references.md b/_includes/references.md index 73e398fa8..38e70dcc0 100644 --- a/_includes/references.md +++ b/_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:info@bitcoinops.org [rss feed]: /feed.xml [scaling payment batching]: /en/payment-batching/ diff --git a/_includes/specials/taproot/en/19-future.md b/_includes/specials/taproot/en/19-future.md index 0c8e588ef..375141d8a 100644 --- a/_includes/specials/taproot/en/19-future.md +++ b/_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 diff --git a/_posts/en/newsletters/2021-02-03-newsletter.md b/_posts/en/newsletters/2021-02-03-newsletter.md index f6d7fe24a..38eda4b1b 100644 --- a/_posts/en/newsletters/2021-02-03-newsletter.md +++ b/_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 diff --git a/_posts/en/newsletters/2021-07-14-newsletter.md b/_posts/en/newsletters/2021-07-14-newsletter.md index 734066229..a72634cc2 100644 --- a/_posts/en/newsletters/2021-07-14-newsletter.md +++ b/_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/ diff --git a/_posts/en/newsletters/2022-03-09-newsletter.md b/_posts/en/newsletters/2022-03-09-newsletter.md index b36bf64ae..f56770999 100644 --- a/_posts/en/newsletters/2022-03-09-newsletter.md +++ b/_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 diff --git a/_posts/en/newsletters/2022-05-18-newsletter.md b/_posts/en/newsletters/2022-05-18-newsletter.md index e4dbb4f56..6d18854cb 100644 --- a/_posts/en/newsletters/2022-05-18-newsletter.md +++ b/_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 diff --git a/_topics/en/op_cat.md b/_topics/en/op_cat.md new file mode 100644 index 000000000..0159d4db5 --- /dev/null +++ b/_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: + + OP_CAT 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="" %} diff --git a/_topics/en/op_checksigfromstack.md b/_topics/en/op_checksigfromstack.md index b00d7e9cf..93f210198 100644 --- a/_topics/en/op_checksigfromstack.md +++ b/_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