salvatoshi

It's CCV o'clock!

I opened a draft PR to bitcoin-inquisition to activate OP_CHECKCONTRACTVERIFY (BIP-443).

https://github.com/bitcoin-inquisition/bitcoin/pull/102

Please help by reviewing, if you can!

This slide summarizes the fundamental reason why forbidding data embeddings on-chain either:

• fails miserably, or
• destroys Bitcoin.

I guess I'll start running v31 today

Fiat money runs on Poof of Work.

You worked, you got paid... and poof, it's gone.

Unpopular (?) opinion: banish the term 'PSBT' from the UI of software wallets (and hardware signers).

It's just a file format. Image-editing tools don't tell you "load JPEG/PNG/..." – it's "Load image".

'Transaction draft'? 'Unfinished transaction'? Just 'transaction'?

All roads lead to CCV. Or at least this one does.

https://github.com/bitcoin/bips/blob/master/bip-0443.mediawiki

I bought an RTX 5090.

What are the coolest self-hosted AI things you guys are doing?

This guy's good – Guinness world record of first merged PRs

Internet up the early 2000s was about finding order in chaos. Lots of energy was bottom-up. Search engines and aggregators would just help you find it; and finding the good content did sometimes feel like uncovering a secret treasure.

How to bring back the chaos?

Seen in ₿ali

Primal hands down had the most fun booth at BtcPrague

Vanadium will make programming apps to run on hardware signing devices almost as easy as programming on your desktop.

https://github.com/LedgerHQ/vanadium

Here are the slides for my talk at

/dev/hack/day:

https://docs.google.com/presentation/u/1/d/1WcV0cLzpJHJY5cJbJncAi8EjXoI5HAh2g6-KQNpE6qc

It's a change of paradigm: you will no longer need to wait for the vendor to implement a missing feature before it's possible to use it with your hardware signer. You can build it yourself!

Honored to sit right next to

on the scoreboard! I'll try again tomorrow :)

The Script Army Knife

OP_CHECKCONTRACTVERIFY OP_CAT OP_CHECKSIGFROMSTACK OP_AMOUNT OP_CHECKTEMPLATEVERIFY

This is a minimal set of opcodes that can implement virtually any of the interesting constructions that I've seen discussed and researched in the last few years.

In fact, I'd challenge anyone to find a compelling construction that cannot be implemented with these opcodes.

The exception is of course some extremely complex operation that cannot fit in a block (or is impractically large) without a custom opcode. Examples are Snark verifiers, BLS signatures, quantum-resistant signatures, other advanced crypto, etc.).

However, for those advanced use cases, MATT fraud proofs (enabled by CCV+CAT) might be a viable substitute for many applications, allowing to get the benefits of those constructions on layer 2 without exposing layer 1 to cryptography that is considered too novel.

Each of these opcodes is simple, has at least a draft implementation, and they are all very composable with each other, and with any possible future Script updates.

What happens in Vegas, hopefully doesn't stay in Vegas.

See you on Thursday!

EUR people wondering why is everyone talking about ATH

My talk at

is Thursday 29th May 1:30pm in the Developer Zone.

Let's chat about useful opcodes.

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

in Vegas and let's keep the ball rolling.

I will be at

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.

https://www.ledger.com/blog-musig2-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: https://delvingbitcoin.org/t/a-simple-backup-scheme-for-wallet-accounts/1607

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 https://image.nostr.build/9ea77f2567d8e50f8a7a98f7f76e32b48e0e5a684ee66a91eb6b154a08020522.jpg

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

https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd

On improving IBD time.

What would be needed in order to make zaps work with bolt12-supporting wallets like Phoenix?

Self-custody can't be evil.

Minimize evil in bitcoin by holding the keys.

"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.

What should a nostr app for signing devices be able to do? I need requirements - writing it is easy.

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 https://image.nostr.build/6cac5d7f657772843e401d5e3f23f0ba10328152cf795a394c1816758611c0c7.jpg https://image.nostr.build/6cac5d7f657772843e401d5e3f23f0ba10328152cf795a394c1816758611c0c7.jpg

Some updates on OP_CHECKCONTRACTVERIFY:

• BIP draft: https://github.com/bitcoin/bips/pull/1793
• bitcoin-core concept implementation: https://github.com/bitcoin/bitcoin/pull/32080
• Delving post: https://delvingbitcoin.org/t/op-checkcontractverify-and-its-amount-semantic/1527

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 https://merkle.fun. I look forward to your comment and ideas.

GM, I'm trying to compile rust-bitcoin without rust-secp256k1. How's your day?

You can't prevent governments from buying bitcoin, but you should strive to make sure governments can't prevent you.

I got various requests over time about supporting certain special Scripts in the Ledger bitcoin app.

It is a delicate topic to support signing arbitrary scripts, and it's not yet clear to me if there's a way that is both generic and secure enough to add to the Ledger bitcoin app. Doing it incorrectly might weaken the security model for existing Scripts.

It is not enough to have enough info in the PSBT to technically sign - the device needs to know what kind of checks needs to be performed on the transaction before signing.

BIP-388 defines a very generic class of Scripts that is still uniform enough to share the same signer's behavior ("you spend from a well-defined account, and change must go back to the same account"), and that's been the focus so far.

Unless a generalization is found that makes sense (and is compatible with BIP-388), custom signing behavior might be better served by separate apps, so that you can have clear signing, a UX that makes sense, and hardened checks for that use case.

I'm working on a solution for that. Please reach out if you have the need for signing certain custom Scripts – it would help to know about your use cases!

Happy year 45x45! Stay laser-focused, and let's make it the best year for Bitcoin, fair and square.

Merry Christmas to those who cerebrate — I hope you have some bright thoughts.

My comments on the proposed opcodes in the "Covenants support" page:

https://gist.github.com/bigspider/2b0892da45884d26eb7f4c9cb2395a7d

I think it's not very meaningful to "support" specific opcodes: most opcodes are not very good in isolation, but might be good in the right combination. A soft-fork can enable multiple opcodes, and it should be a coherent set of changes that does one or a few things well.

Therefore, I think it's more important to identify and discuss the "primitives" that the opcodes (and packages of opcodes) can enable.

I identify the following tentative list of primitives enabled (one way or another) by the various proposals:

• commitments to transactions
• signing a message
• vector commitments
• concatenation
• state-carrying UTXOs
• multi-step transactions
• generic introspection

I argue that if some opcodes poorly enable a valuable primitive, then other opcodes that implement that primitive well should be enabled together. Otherwise, we're shooting ourselves in the foot with the bloat that will inevitably come.

I discuss my opinion on whether or not it might be dangerous to enable new primitives in Script.

Finally, I suggest a potential minimal package of opcodes that would enable all the identified primitives pretty well, while each is fairly simple and self-contained:

• OP_CTV
• OP_CAT
• OP_CCV
• OP_CSFS
• OP_AMOUNT

To me, quantum computing is an attempt to cheat nature. I think (and hope) that it won't work. I like the Church-Turing thesis, and I'd like the model of "what computation is" to be something that the human brain can understand without a PhD in physics.

Grover's algorithm, for me, is not a "result" of quantum computing. It is the counterexample. You mean to say that you can find a specific object among a random collection of N objects in just sqrt(N) work? Give me a break!

My bet is that something that is not yet understood will physically prevent scaling quantum computers. You want reliable quantum computation with n bit? Then the cost of running this machine will grow exponentially in n.

Join the Church-Turing maxis, say #NoToQuantumComputers

At

in Austin this May, I presented the pymatt Python framework, showing how to use it to implement vaults that are comparable to OP_VAULT using OP_CHECKCONTRACTVERIFY + OP_CTV.

Timestamps:

• Intro to MATT: https://youtube.com/watch?v=BvXI1IOargk&t=67s
• Vaults: https://youtube.com/watch?v=BvXI1IOargk&t=898s
• Vault demo: https://youtube.com/watch?v=BvXI1IOargk&t=1573s
• Code in pymatt: https://youtube.com/watch?v=BvXI1IOargk&t=1898s

V for V _ n _ _ _ _ _

Coming in 2025.

You might be hit by a sjorsnado

See you at

!

If you're working on a MuSig implementation and you have a Ledger device (except Nano S), feel free to test the "Bitcoin Test Musig" app!

Instructions on this repo; you'll be able to sign testnet transactions using musig (both in the keypath, or the script path) in 5 mins.

https://github.com/LedgerHQ/moosig

If you often use regtest, you often need to manually mine blocks to test things.

If you're on linux, add this to ~/.bashrc:

mine() {
  if [ "$#" -eq 0 ]; then
    bitcoin-cli -regtest -generate 1
  else
    bitcoin-cli -regtest -generate "$1"
  fi
}

alias mine=mine

Now you can write:

  $ mine

to mine a block, or:

  $ mine 100

to mine 100 blocks and make your Liana timelocks expire.

Another useful alias for .bashrc:

alias lastblock='bitcoin-cli -regtest getblock $(bitcoin-cli -regtest getbestblockhash) 2'

So you can just write 'lastblock' on the terminal to see all the transactions in the last block.

Please reply below with your best regtest aliases and scripts.

Spoiler: the solution to good UX in hardware signers is not removing the screen.

I can't even

I'm excited to be coming to TabConf in Atlanta in October 23-26th. My talk will revolve around the UX of hardware signers. It's a technical take on why we failed to build a good UX, and what we can do about it.

Also, please find me if you want to talk about MATT! https://merkle.fun

I use Amethyst and Phoenix. Can I use it to receive zaps? If not... why not?