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

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: 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 TABConf 6, I gave a talk on the UX challenges of hardware signing devices.

Video:

Slides: https://docs.google.com/presentation/d/17Tmwmi93ICXnFb_MTEspoE4TfiLFx6NUKARW5MJsp_M/edit?usp=sharing

I talk about why it's hard (but not unsolvable!) to provide a good and secure UX for complex spending policies.

Then, I discuss about the biggest offender: addresses.

TL;DR:

Today's UX of signing devices is centered around low-level objects of the bitcoin protocol: addresses, and transactions.

My claim is that a good UX can only be built by redesigning it around two much more familiar concepts:

    accounts   and   identity

Working on secure support for descriptors & #miniscript, my initial focus has been to provide a secure flow with a good enough UX to be usable in practice.

And if you tried #Liana, you know it is!

But registration is certainly not yet optimal.

When you register a new miniscript policy, you teach your device to recognize all present and future addresses of the account described by that policy. Once registration is finished, you have a UX that is not more complicated than your typical single-sig transaction.

Thanks to this registration of BIP-388 wallet policies (https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki), any additional complexity coming from the fancy scripts is limited to a one-time event. While not ideal, that's acceptable; it takes just a few minutes to go through the entire registration flow.

But that's hardly the end of the story. Our brain is just bad at processing addresses, and this makes people lose money.

https://x.com/mononautical/status/1796939795127500996

The key observation is that while accounts solve the UX problems for the internal UTXOs in a transaction (that is, the inputs you're spending, and also the change outputs), we're still offloading to the user the responsibility of checking the address of the external outputs. But the user doesn't care about the address where the money is going.

The user only cares about who owns the address. If the signing device can guarantee that you Send 0.1 ₿ to Bob than that's all the the users really cares to check. Bob's address is Bob's business.

Therefore, what we want in payment instructions is not just addresses, but rather authenticated addresses: information that is given to wallets and signers must be enough to guarantee the provenance of the address. So, how can we authenticate addresses?

That's the hard part. Not because it's difficult, but because there's no one-size-fits-all solution, and the best way depends on the specific situation. But there are several promising approaches.

In same cases, we could use the account information! After all, if we're sending to another of your accounts, or your partner's account, or maybe the account of some other business unit of your company, then the receiver might be happy to share the BIP-388 wallet policy with you.

Today, we're only using the account info to authenticate the inputs and the change address. If that info is added to the PSBT for external outputs, we could show: Send 0.1 ₿ to your wife's account which would surely be a better UX!

Something that clicked for me recently is the following: Silent Payments (BIP-352) are just another type of account! They can fit perfectly well in this account-based UX flow. They are inherently tied to an identity, and they allow you to generate authenticated addresses.

Finally, if knowledge of the receiving account isn't possible, there's still something that we can do: have the owner sign the address.

If we have a guarantee that the key signing the address belongs to the expected receiver, then we can spare the user from checking the address. You could exchange keys in person if that's feasible; or approaches like BIP-353 (https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki) using DNS might be practical in many situations - for example, for public entities like companies and exchanges.

Identity would also help in further improving the UX of account registration: the xpub of your cosigners could also be authenticated in the same way, simplifying the registration flow:

I hope to inspire more people to think about this problem.

There is still a lot to do, for example:

• What is the best way to present the spending policy of a complex miniscript-based account to the user?
• How to encode the 'account' information in the PSBT?
• What support should hardware signers provide to support identity and authentication of addresses/xpubs?

There is nothing inherently difficult in tackling this. No fancy cryptography or moon math is required.

Just good standards to properly define and implement across vendors and wallets.

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.

Amethyst could maybe add a "call to action" when this happens: what can the user do to fix the situation? Nothing happens when I tap it. cc

You might be hit by a sjorsnado