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.

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.