salvatoshi on Nostr: Merkleize nothing! I posted on bitcoin-dev about some progress on formalizing the ...
Merkleize nothing!
I posted on bitcoin-dev about some progress on formalizing the MATT opcodes, and a demonstration on how a vault could look like in MATT.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html
And here's the accompanying code:
https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...bigspider:bitcoin-inquisition:matt-vault
By talking a lot about Merkle trees and fraud proofs, I might have given the wrong impression that writing contracts in MATT is complicated.
The code I shared aims to convince you otherwise!
I implemented a prototype of vaults that tries to follow most of jamesob's design.
Despite the opcodes of MATT not having any vault-specific functionality, the resulting scripts are quite simple and inexpensive.
The construction only uses the core opcodes of MATT: OP_CHECK{INPUT,OUTPUT}CONTRACTVERIFY.
Since vaults require very little data passing (a single hash), no Merkle trees are required in this construction.
I hope this disproves a common stigma around general-purpose opcodes for bitcoin smart contracts: "Constructions are complicated".
That was only true for the "accidental" covenants built on top of OP_CAT or OP_CHECKSIGFROMSTACK, but it's not true for carefully designed opcodes.
Designing state machines using CICV/COCV is actually quite straightforward, and only gets difficult if you build complicated stuff.
I hope this inspires more people to think about these opcodes, and to tinker with them, now that there's some initial code.
I posted on bitcoin-dev about some progress on formalizing the MATT opcodes, and a demonstration on how a vault could look like in MATT.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html
And here's the accompanying code:
https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...bigspider:bitcoin-inquisition:matt-vault
By talking a lot about Merkle trees and fraud proofs, I might have given the wrong impression that writing contracts in MATT is complicated.
The code I shared aims to convince you otherwise!
I implemented a prototype of vaults that tries to follow most of jamesob's design.
Despite the opcodes of MATT not having any vault-specific functionality, the resulting scripts are quite simple and inexpensive.
The construction only uses the core opcodes of MATT: OP_CHECK{INPUT,OUTPUT}CONTRACTVERIFY.
Since vaults require very little data passing (a single hash), no Merkle trees are required in this construction.
I hope this disproves a common stigma around general-purpose opcodes for bitcoin smart contracts: "Constructions are complicated".
That was only true for the "accidental" covenants built on top of OP_CAT or OP_CHECKSIGFROMSTACK, but it's not true for carefully designed opcodes.
Designing state machines using CICV/COCV is actually quite straightforward, and only gets difficult if you build complicated stuff.
I hope this inspires more people to think about these opcodes, and to tinker with them, now that there's some initial code.