Merkleize nothing! I posted on bitcoin-dev about some progress on formalizing the ...

npub157y…60gr

2023-04-25 08:20:52

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.

Author Public Key

npub157y6gz0l0rfhw220rfwnujeff6q2mec33nzkwz23umkrt6482exq8e60gr

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-04-25 08:20:52

Kind type

1 Short Text Note

Event JSON

{ "id": "fbf709fbc4cba5ba4f371624ce864b113cbfb6472cfe874ef7cc3127f68f24fb", "pubkey": "a789a409ff78d377294f1a5d3e4b294e80ade7118cc5670951e6ec35eaa7564c", "created_at": 1682410852, "kind": 1, "tags": [], "content": "Merkleize nothing!\n\nI posted on bitcoin-dev about some progress on formalizing the MATT opcodes, and a demonstration on how a vault could look like in MATT.\n\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html\n\nAnd here's the accompanying code:\n\nhttps://github.com/bitcoin-inquisition/bitcoin/compare/24.0...bigspider:bitcoin-inquisition:matt-vault\n\n\nBy talking a lot about Merkle trees and fraud proofs, I might have given the wrong impression that writing contracts in MATT is complicated.\n\nThe code I shared aims to convince you otherwise!\n\nI implemented a prototype of vaults that tries to follow most of jamesob's design.\n\n\nDespite the opcodes of MATT not having any vault-specific functionality, the resulting scripts are quite simple and inexpensive.\n\nThe construction only uses the core opcodes of MATT: OP_CHECK{INPUT,OUTPUT}CONTRACTVERIFY.\n\n\nSince vaults require very little data passing (a single hash), no Merkle trees are required in this construction.\n\nI hope this disproves a common stigma around general-purpose opcodes for bitcoin smart contracts: \"Constructions are complicated\".\n\n\nThat 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.\n\nDesigning state machines using CICV/COCV is actually quite straightforward, and only gets difficult if you build complicated stuff.\n\n\nI hope this inspires more people to think about these opcodes, and to tinker with them, now that there's some initial code.", "sig": "ba099cecfeb526d3b97438550b1c48d106abbd346c82f139770a096f4b7fb5a2116459295f40f57c948c2e15e7d2e65fca9869820da905eeca0ad6169ca7a2c0" }