├── .gitignore ├── CNAME ├── FAQ.md ├── LICENSE ├── README.md ├── assets └── merkletree.png ├── binarytree.jpg └── favicon.ico /.gitignore: -------------------------------------------------------------------------------- 1 | _site/ 2 | .sass-cache/ 3 | .jekyll-cache/ 4 | .jekyll-metadata 5 | -------------------------------------------------------------------------------- /CNAME: -------------------------------------------------------------------------------- 1 | merkle.fun -------------------------------------------------------------------------------- /FAQ.md: -------------------------------------------------------------------------------- 1 | # Frequently Asked Questions (FAQ) 2 | 3 | 1. [General Questions](#general-questions) 4 | - [What is MATT?](#what-is-matt) 5 | - [What is `OP_CHECKCONTRACTVERIFY`?](#what-is-op_checkcontractverify) 6 | - [Are there other ways to enable MATT constructions?](#are-there-other-ways-to-enable-matt-constructions) 7 | - [Does MATT make bitcoin's Script Turing-complete?](#does-matt-make-bitcoins-script-turing-complete) 8 | - [Exciting! How can I write MATT smart contracts?](#exciting-how-can-i-write-matt-smart-contracts) 9 | 2. [Fraud Proofs](#fraud-proofs) 10 | - [What is a fraud proof?](#what-is-a-fraud-proof) 11 | - [Do MATT contracts need fraud proofs?](#do-matt-contracts-need-fraud-proofs) 12 | - [Do MATT fraud proofs actually scale?](#do-matt-fraud-proofs-actually-scale) 13 | - [Could future upgrades of bitcoin Script make fraud proofs unnecessary?](#could-future-upgrades-of-bitcoin-script-make-fraud-proofs-unnecessary) 14 | - [What are the trade-offs of fraud proofs?](#what-are-the-trade-offs-of-fraud-proofs) 15 | - [Can miners just steal from fraud proof protocols?](#can-miners-just-steal-from-fraud-proof-protocols) 16 | 3. [Design Choices](#design-choices) 17 | - [Does MATT allow recursive covenants?](#does-matt-allow-recursive-covenants) 18 | - [Could the "data" of MATT contracts be committed somewhere else?](#could-the-data-of-matt-contracts-be-committed-somewhere-else) 19 | 4. [Related Work](#related-work) 20 | - [How does MATT compare with BitVM?](#how-does-matt-compare-with-bitvm) 21 | 22 | 23 | ## General Questions 24 | 25 | 26 | ### What is MATT? 27 | 28 | MATT is a minimalistic approach to smart contracts designed to require only simple, non-invasive changes to Bitcoin consensus rules, yet bring a large increase in expressive power. 29 | 30 | This is achieved by means of an extensive use of [Merkle trees](https://en.wikipedia.org/wiki/Merkle_tree), with multiple purposes. MATT is an acronym of *Merkleize All The Things*. 31 | 32 | The core new Script primitive introduced in MATT is the ability to: 33 | - force an output to have a certain Script, and control its amount 34 | - attach a small piece of data to an output 35 | - 'read' the data of an input (usually the current one) 36 | 37 | The second ingredient which is necessary in order to achieve generality is the ability to "compress" multiple pieces of data into single 32-byte hash, which can be achieved with Merkle trees. 38 | 39 | There are many ways to introduce the MATT functionality with new opcodes, and constructions based on MATT are easy to port to any approach that provides the necessary functionality. 40 | 41 | 42 | ### What is `OP_CHECKCONTRACTVERIFY`? 43 | 44 | `OP_CHECKCONTRACTVERIFY` is a proof-of-concept of an opcode that directly implement the core functionality of MATT. It is designed to be clean and generic, and to work well with P2TR (taproot) scripts. 45 | 46 | In short, `OP_CHECKCONTRACTVERIFY` can be summarized as follows: *Check that an input/output is a P2TR output whose public key is obtained by tweaking a certain key with ``, and then with ``*. The opcode can also constrain the output amount - in the most common case, by forcing all the amount of the current input to be preserved in an output. 47 | 48 | A formalization of the semantic of the opcode is [here](https://github.com/ariard/bitcoin-contracting-primitives-wg/issues/25#issuecomment-1595762674). 49 | 50 | Together with `OP_CAT`, it's a complete, and straightforward implementation of the MATT proposal. 51 | 52 | Additional opcodes could be useful to make constructions better or more efficient, but they are not strictly required for MATT. 53 | 54 | 55 | **Warning:** Note that the current `OP_CHECKCONTRACTVERIFY` implementation is a proof-of-concept and has not received extensive testing and review. It has the goal to develop the framework and experiment with arbitrary MATT contracts, but it does not satisfy the quality standards for a soft-fork proposal. 56 | 57 | 58 | ### Are there other ways to enable MATT constructions? 59 | 60 | Yes, the core functionality of MATT is quite basic, and it's possible to obtain it by combining several general-purpose opcode. For example, the following opcodes are enough: 61 | 62 | - `OP_CAT` (concatenate two elements) 63 | - introspection of input/output script and amounts 64 | - `OP_TWEAK` (scalar multiplication of a secp256k1 point) 65 | 66 | Of course, optimizing the opcodes to the typical pattern of MATT contracts helps its usability and the script size of the constructions using it. 67 | 68 | 69 | ### Does MATT make bitcoin's Script Turing-complete? 70 | 71 | No, Script remains simple and *not* Turing-complete. 72 | 73 | MATT only enables UTXOs to enforce simple state machines, where each state transition (corresponding to a bitcoin transaction) is simple enough to be computed (or, rather, verified), in Script. 74 | 75 | Very long state machines could in theory be used to compute any function; however that wouldn't be feasible in practice for complicated functions. 76 | 77 | However, a rather simple state machine is enough to implement a *fraud proof protocol* for arbitrary computation. 78 | 79 | Therefore, while Script will still only be able to verify relatively simple predicates, it enables smart contracts that depend on the result of arbitrary computation. 80 | 81 | Thanks to fraud proofs, one can argue that *any possible technology that is interesting for bitcoin could be implemented as a layer two*. That holds even for applications that require cryptographic techniques that are not available to bitcoin's layer 1. 82 | 83 | Of course, fraud proofs come with trade-offs that need to be assessed in the context of each specific application. 84 | 85 | 86 | ### Exciting! How can I write MATT smart contracts? 87 | 88 | [pymatt](https://github.com/Merkleize/pymatt) is an experimental framework to write smart contracts using the MATT approach. Together with the [docker container](https://github.com/Merkleize/docker), you can get started writing and testing smart contracts on `regtest` in no time. 89 | 90 | 91 | ## Fraud Proofs 92 | 93 | ### What is a fraud proof? 94 | 95 | The idea of fraud proofs is to replace a (possibly expensive) computation in a smart contract with just a claim that a computation would give a certain result. 96 | 97 | As long as the interested parties in the contract have a way of disproving fraudulent claims, and the contract is constructed in such a way that fraud attempts are punished, then frauds (and fraud proofs) are never expected to actually end up on chain. 98 | 99 | The saving generally comes not only from avoiding an expensive operation in Script, but also by not putting the entire witness data that the computation would need: a commitment to it is generally sufficient, as long as the counterparties are able to independently compute the correct data themselves. 100 | 101 | The trade-off of using protocols based on fraud proofs (optimistic protocols) in comparison to a full on-chain validation of the contract transition are: 102 | 103 | - fraud proofs require a challenge period, in comparison to direct computations that are confirmed in a single transaction; moreover, some capital lockup is generally needed during the challenge period; 104 | - fraud proof protocols rely on the assumption that miners are not actively censoring the transactions of a party in the smart contract (and blocks containing them). 105 | 106 | The most commonly used optimistic protocol in bitcoin today is in a Lightning channel: the “justice transaction” that is published if a counterparty puts an old state on-chain is indeed a fraud proof. 107 | 108 | 109 | ### Do MATT contracts need fraud proofs? 110 | 111 | No! 112 | 113 | Fraud proof protocols are one of the things that can be built with MATT¸ and can be used as a building block for other smart contracts. They greatly expand the realm of what's possible in Bitcoin Script. 114 | 115 | In a certain sense, *any possible layer-2 system can be implemented on Bitcoin using MATT*, thanks to fraud proofs. 116 | 117 | However, constructions that do not require fraud proofs if implemented with other covenant proposals are likely to not require fraud proofs if implemented with MATT. 118 | 119 | 120 | ### Do MATT fraud proofs actually scale? 121 | 122 | Yes! 123 | 124 | A well designed smart contract based on fraud proofs can make sure that actually executing a fraud proof on-chain is never expected to happen. That's because uncooperative parties are financially punished, making honest behaviour always the cheapest option. 125 | 126 | Of course, it is still important that fraud proofs *can* be brought and completed on chain if needed. 127 | 128 | A ballpark estimate based on a current, unoptimized implementation suggests that a MATT fraud proof will never require more than 15000 vbytes (for a computation with 2^32 = 4 billion steps!), and it's reasonable to expect that, in practice, the total size would rarely go beyond a few thousands vbytes. 129 | 130 | 131 | ### Could future upgrades of bitcoin Script make fraud proofs unnecessary? 132 | 133 | Smart contract protocols that rely on fraud proofs rather than full on-chain verification are called *optimistic*. 134 | 135 | Optimistic smart contract have the inherent advantage of allowing on-chain settlement to depend on state changes that happen entirely off-chain. For example, in a lightning channel, one has a reasonable guarantee that a payment has gone through without any on-chain transaction: they obtained the necessary signatures/preimages from the counter-party and they know they can win an on-chain challenge if necessary. 136 | 137 | This is simply not possible without some kind of challenge mechanism, as the statements that need to be validated depend on data that was never stored (nor committed to) on-chain. 138 | 139 | 140 | ### What are the trade-offs of fraud proofs? 141 | 142 | The trade-offs depend on the specific application fraud proofs are used for. 143 | 144 | Generally speaking, some of the common trade-offs of optimistic contracts are: 145 | 146 | - *Capital lockup*: funds are only available after a challenge period, rather than immediately. Moreover, optimistic protocols usually require some additional capital to be locked in a contract, in order to keep participants honest and make *griefing* expensive for dishonest participants. 147 | - *Censorship resistance assumption*: Optimistic protocols rely on censorship resistance at layer 1, since the inability to get transactions confirmed in time would lead to loss of funds. 148 | 149 | 150 | ### Can miners just steal from fraud proof protocols? 151 | 152 | A single miner or entity controlling less than 50% of the hashrate only has a slight advantage if they are a party in a challenge protocol: even if they censor the counterparty's transactions, some other miner will have an incentive to confirm the other party's transactions if they pay high-enough fees. 153 | 154 | A full blown 51% attack, where the attackers censor the other side's transactions, *and reject any block that includes them*, can win all challenges. That differs from regular on-chain transactions, where even a hashrate majority can permanently censor, but not steal funds. 155 | 156 | This is an inherent tradeoff of optimistic protocols. 157 | 158 | The degree of how worrisome this attack vector is depends on at least two factors: 159 | - *Challenge openness*: if only a few parties in the contract can initiate a challenge, the 51% attack is only an issue if the counterparties collude with the offending miners. Protocols where anyone can start a fraud proof might be easier to attack. 160 | - Stakes: contracts with much higher stakes would increase the reward for a successful attack. 161 | 162 | The lightning network is vulnerable to this attack, but sits at the lowest end of the spectrum: only the counterparty can attempt to fraudulently win a challenge, and the amount locked in a single lightning channel is usually not extremely high. Therefore, a wannabe-51%-attacker would probably need to prepare an attack over a long time, locking capital in many different lightning channels, and attack all of them simultaneously. 163 | 164 | On the opposite end of the spectrum, a hypothetical *optimistic sidechain* locking a large amount of capital, with completely open access and a 2-way peg based on fraud proofs would be most vulnerable to a 51% attack. 165 | 166 | 167 | ## Design choices 168 | 169 | 170 | ### Does MATT allow recursive covenants? 171 | 172 | This depends on how it is implemented. The current implementation of `OP_CHECKCONTRACTVERIFY` allows recursion. While most smart contracts do not need recursion, it is a useful feature for some of them. For example, the [vaults](https://github.com/Merkleize/pymatt/tree/master/examples/vault) demo uses it to allow partial revaulting - a nice-to-have, rather than an essential feature. 173 | 174 | However, it is possible to design opcodes that enable the functionality of MATT without unbounded recursion. A limited recursion depth of a few tens (or perhaps less) transactions is sufficient to implement fraud proof protocols for arbitrary computation. 175 | 176 | 177 | ### Could the "data" of MATT contracts be committed somewhere else? 178 | 179 | Yes, there are many possible approaches, and they make different tradeoffs. 180 | 181 | `OP_CHECKCONTRACTVERIFY` uses a double *tweak* in order to commit to the data. 182 | 183 | A tweak is a technique that allows to embed a piece of data inside a valid public key. This is used in taproot outputs to allow the pubkey to implicitly 'contain' (in cryptographic terms, it's a *commitment*) the root of the Merkle tree of all the Script spending conditions. `OP_CHECKCONTRACTVERIFY` repeats this trick twice: once to encode 184 | the data of the smart contract, and another time to contain the regular taproot Merkle tree as expected in Pay-2-Taproot. 185 | 186 | Pros: 187 | - The approach remains fully compatible with Pay-2-Taproot UTXOs. 188 | - The size of the UTXOs is not increased. 189 | - The cost of revealing the data is only paid for Scripts that require this data. 190 | - It is rather elegant to not mix the contract *data* with the *program* (the taptree). 191 | 192 | Cons: 193 | - A tweak is computationally a rather expensive operation. 194 | 195 | An alternative approach could be to embed the data as a "fake" tapleaf in the taptree. However, if a leaf next to the root is used, the cost of using *every* tapscript increases (regardless if they access the data or not); if a deep tapleaf is used, then the cost of revealing the data increases substantially for contracts with multiple tapleaves. However, this approach would avoid the expensive data tweak. 196 | 197 | Another approach could be a completely new SegWit version, which would allow more freedom in how to design the features required for MATT; however, this would dramatically increase the size of the required code changes, and it is unclear if it would have substantial benefits. 198 | 199 | 200 | ## Related work 201 | 202 | ### How does MATT compare with BitVM? 203 | 204 | [BitVM](https://bitvm.org/bitvm.pdf) is the remarkable discovery that a channel (among two or more fixed parties) that allows fraud proofs for arbitrary computations is possible today in bitcoin. Such channels are known in academic literature as *state channels*, and they can be considered a generalization of lightning channels where the parties are able to play an arbitrary game. The game can be played entirely off-chain if there's cooperation; otherwise, the other parties can *force* the game to be played on-chain. 205 | 206 | However, MATT is more general, as it enables contracts that implement arbitrary on-chain state machines, rather than just *channels*. 207 | 208 | In fact, something as simple as an on-chain [vault](https://github.com/Merkleize/pymatt/tree/master/examples/vault) construction is not possible with BitVM, while it is enabled by an explicit soft-fork for covenants. 209 | 210 | The lack of covenants comes at a hefty cost: BitVMs channel require a large precomputation, with significant storage and bandwidth requirements prior to setup. 211 | 212 | State channels implemented with MATT require no precomputation whatsoever, and an on-chain execution of a fraud proof protocol is expected to be orders of magnitude cheaper than with BitVM. 213 | 214 | Read a more detailed comparison in [this Twitter thread](https://twitter.com/salvatoshi/status/1712772143753408824). 215 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # MATT (Merkleize All The Things) 2 | 3 | MATT is an approach for bitcoin smart contracts that is designed to be extremely simple, yet powerful.
4 | It could be enabled as a *soft fork* with various combinations of opcodes. The most direct way is based on an opcode called OP_CHECKCONTRACTVERIFY (CCV). 5 | 6 | Key applications include: 7 | 8 | - **Scaling and privacy** with more powerful layer 2 constructions. 9 | - **Trustless bridges** for optimistic rollups or other sidechains. 10 | - **Vaults** for better self custody. 11 | 12 | By enabling scalable *fraud proof* protocols for arbitrary computations, it would bring permissionless innovation in the bitcoin's layer 2 space, while keeping Bitcoin's layer 1 simple and minimalistic. 13 | 14 | **Start here**
15 |     [Gentle introduction on StackExchange](https://bitcoin.stackexchange.com/questions/119239/what-are-matt-opcodes/119268#119268): *A beginner-friendly explanation of MATT and its core concepts.*
16 |     [FAQ](FAQ.md) *Answers to common questions about MATT, its implementation, and use cases.* 17 | 18 | 19 | **Specs and implementation**
20 |     [BIP-443](https://github.com/bitcoin/bips/blob/master/bip-0443.mediawiki)
21 |     [bitcoin-core implementation](https://github.com/bitcoin/bitcoin/pull/32080)
22 |     [Discussion on the *amount* logic of OP_CHECKCONTRACTVERIFY](https://delvingbitcoin.org/t/op-checkcontractverify-and-its-amount-semantic/1527)
23 | 24 | 25 | **Presentations**
26 | [▶️ Merkleize All The Things](https://www.youtube.com/watch?v=56_rItUgrbA). *Advancing Bitcoin Conference − London, March 2nd, 2023*. [Slides](https://docs.google.com/presentation/d/1VCHJhXXzjn3qggQfNTZ3Ikiwi4QaXQYZzqkAea-QCBc/edit)
27 | *An introduction to MATT and how it enables scalable fraud proofs on Bitcoin.* 28 | 29 | [▶️ sMATT Contracts Zero to Hero](https://youtu.be/BvXI1IOargk?si=dDi-7UdcO8OjCpGh). *btc++ − Austin, May 3rd, 2024*. [Slides](https://docs.google.com/presentation/d/1mcAJgPr7sBUZvT_0CBgY4NlkhUPiTpreUM4_YVx_g4o/edit)
30 | *A deep dive into MATT and the pymatt Python framework, with a re-implementation of [James O’Beirne's vaults](https://jameso.be/vaults.pdf) using CCV.*
31 | Timestamps:
32 |     [Intro to MATT](https://youtube.com/watch?v=BvXI1IOargk&t=67s)
33 |     [Vaults](https://youtube.com/watch?v=BvXI1IOargk&t=898s)
34 |     [Vault demo](https://youtube.com/watch?v=BvXI1IOargk&t=1573s)
35 |     [Code in pymatt](https://youtube.com/watch?v=BvXI1IOargk&t=1898s) 36 |
37 | 38 | **Programming with MATT** 39 | - [Docker image](https://github.com/Merkleize/docker) of bitcoin-inquisition + OP_CHECKCONTRACTVERIFY + OP_CAT + OP_CTV for regtest. 40 | - [pymatt](https://github.com/Merkleize/pymatt) Python framework for MATT smart contracts, and examples. 41 |
42 | 43 | **Research** 44 | - [Games in the head (and fraud proofs for the plebs)](https://delvingbitcoin.org/t/games-in-the-head-and-fraud-proofs-for-the-plebs/446): an exploration on how to optimize 2-party fraud proof protocols implemented with MATT, and an estimate of the worst-case on-chain costs. 45 | - [Aggregate delegated exit for L2 pools](https://delvingbitcoin.org/t/aggregate-delegated-exit-for-l2-pools/297): an approach for a fraud-proof based exit protocol for shared UTXOs that would allow many users to cooperate in order to withdraw their money. 46 | - [elftrace](https://github.com/halseth/elftrace): Johan Torås Halseth's prototype of a compiler for arbitrary computation to RISC-V, and verify in Bitcoin Script via MATT's fraud proofs. 47 | - [▶️ Optimistic execution of RISC-V in Tapscript](https://youtu.be/byD4N2oLhFY?si=37E1oFbSVISngjo5): Presentation at *btc++ − Austin, May 1st, 2024*. 48 | 49 | **bitcoin-dev** 50 | - [Original bitcoin-dev post](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html) 51 | - [Example of fraud proof protocol instance](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021205.html) 52 | - [Vaults in the MATT framework](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html) and [code example](https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...bigspider:bitcoin-inquisition:matt-vault) 53 | - [MATT plays Rock-Paper-Scissors](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021599.html) + [errata](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021604.html) 54 | - [Johan Torås Halseth](https://twitter.com/johanth)'s demonstration of [CoinPools exit clause](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021719.html) using MATT and Merkle trees. [(docs)](https://github.com/halseth/tapsim/tree/matt-demo/examples/matt/coinpool) + [(code)](https://github.com/halseth/tapsim/blob/matt-demo/examples/matt/coinpool/script.txt) 55 | -------------------------------------------------------------------------------- /assets/merkletree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Merkleize/matt/896ea0131ddc0e6790e96ae22ff5cc4f44159535/assets/merkletree.png -------------------------------------------------------------------------------- /binarytree.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Merkleize/matt/896ea0131ddc0e6790e96ae22ff5cc4f44159535/binarytree.jpg -------------------------------------------------------------------------------- /favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Merkleize/matt/896ea0131ddc0e6790e96ae22ff5cc4f44159535/favicon.ico --------------------------------------------------------------------------------