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: https://github.com/bitcoin/bips/pull/1793 - 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.

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

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

Gist

Opcodes Zoo

Opcodes Zoo. GitHub Gist: instantly share code, notes, and snippets.

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