OP_CHECKCONTRACTVERIFY is BIP-443. When I presented MATT at the first @btcazores in September 2022, it was just a concept: a minimal covenant with maximal power. While the covenant was straightforward, what a good implementation would look like was far from clear. Then came James O'Beirne's OP_VAULT proposal - a narrower, practical use case for a covenant. And yet, it resonated: the underlying need was the same as in MATT. Both required a way for coins to carry state (data) from input to output. If two very different problems point to the same technical tool, maybe that tool is a solid foundation. CCV implements that foundation. CCV is not made for vaults, but it enables them (alone, or supercharged with CHECKTEMPLATEVERIFY). CCV is not "MATT's opcode", but it's the main building block. CCV is also what bridges like BitVMs are simulating with workarounds like Lamport Signatures: updating the state. It makes large part of their on-chain footprint redundant, and greatly simplifies their design. There's no more for cabooses, CatVMs, ColliderVMs. Script will finally have an expressive primitive for carrying state in UTXOs. --- There is still a lot of work to do. The implementation needs to be reviewed and improved, ideally to be made ready for signet. More tooling needs to be developed. More work is necessary to assess what combinations of opcodes work best for a soft-fork. CCV has no sponsors and no funding. Can you help? Find me at @The Bitcoin Conference in Vegas and let's keep the ball rolling.

I will be at @The Bitcoin Conference in Vegas with a session on `OP_CHECKCONTRACTVERIFY`. What should I talk about?

Security/privacy ⇒ Entropy Entropy ⇒ Information content

"MuSig2 is the cherry on top of the taproot cake" I'm somewhat of a poet myself. Read about Ledger Bitcoin app's support of MuSig2 in this blog post - written with the legend Yannick Seurin in person.

Ledger

MuSig2 Has Arrived in Version 2.4.0 of Ledger Bitcoin App | Ledger

Learn all about Bitcoin’s latest multisignature evolution – MuSig2 – which has now arrived in version 2.4.0 of Ledger Bitcoin app.

If you use any wallet that is not single-signature (multisig, miniscript, etc.), it is important to have a backup of the descriptor/wallet policy. But we have no standard on how to do it. How should we do it? Here's my attempt at an ideal approach:

Delving Bitcoin

A simple backup scheme for wallet accounts

For any wallet account that is not single-signature, backing up the descriptor is crucial, as its loss is likely to be catastrophic and lead to los...

The approach I propose tries to achieve a number of desirable properties: - Encrypted: so you can outsource its storage; - Easy to implement: really, it's very simple; - Vendor-independent: it should work with any signing device; - Deterministic: the backup should be repeatable. In the post, I try to give motivation on the approach, and come with a scheme that tries to be pragmatic, and easy to adopt. Of course, variations, more features, etc. are possible, but I believe this scheme is good for the use cases of the typical user. And certainly, good enough is better than the status quo where most wallets just tell the user "you should have a backup" 🙃 What do you think?

Not sure why people think Merkle trees are hard.

New polymarket just dropped

When Ruben Somsen writes a gist, you know it's going to be good:

Gist

SwiftSync - smarter synchronization with hints

SwiftSync - smarter synchronization with hints. GitHub Gist: instantly share code, notes, and snippets.

On improving IBD time.

"Don't be evil", as Google taught us, is not a viable long-term strategy for businesses working with content. "Can't be evil" is the way.

Thanks to bitcoin-core developers for merging the next soft-fork! Merkle trees can't be stopped.

Writing apps for hardware signing devices is about to get this easy ``` #![cfg_attr(target_arch = "riscv32", no_std, no_main)] extern crate alloc; use alloc::vec::Vec; sdk::bootstrap!(); fn process_message(_app: &mut sdk::App, msg: &[u8]) -> Vec<u8> { msg.to_vec() } pub fn main() { sdk::App::new(process_message).run(); } ```

Fun

Release 2.4.0 of the Ledger Bitcoin app is out. Codename: "Let the Musig play" It comes with full MuSig2 support for taproot spending policies (both in the keypath and in scripts). Note: at this time, only the python client library is updated with MuSig2 support.

Some updates on OP_CHECKCONTRACTVERIFY: - BIP draft:

GitHub

BIP 443: OP_CHECKCONTRACTVERIFY by bigspider · Pull Request #1793 · bitcoin/bips

Hi all, This is a draft for the formal specifications of the OP_CHECKCONTRACTVERIFY (CCV) opcode. CCV enables to build Script-based state machines ...

- bitcoin-core concept implementation:

GitHub

OP_CHECKCONTRACTVERIFY by bigspider · Pull Request #32080 · bitcoin/bitcoin

This is a first draft implementation of the OP_CHECKCONTRACTVERIFY (CCV) opcode. CCV enables to build Script-based state machines that span across ...

- Delving post:

Delving Bitcoin

OP_CHECKCONTRACTVERIFY and its amount semantic

I have done some work on formalizing the semantic of OP_CHECKCONTRACTVERIFY. I also wrote the first draft BIP and an implementation in bitcoin-cor...

In the new post on delving, I delve into the amount logic of CCV, something that has somewhat evolved since the initial posts. I argue that while scriptPubKey checks are just equality checks this transaction-wide logic is preferable, and it's difficult to replicate it otherwise. However, while the amount logic is not difficult, transaction-wide checks present some implementation challenges, because of multi-threaded Script validation in core. Solving this seems to be necessary for several possible soft forks (CCV, VAULT, TXHASH, CISA), but even just to implement batch validation for Schnorr signatures, which is an optimization available today. More details in the PR. As usual, you'll find all the links at

matt

MATT (Merkleize All The Things)

The revolution will be merkleized

I look forward to your comment and ideas.