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

GitHub

GitHub - LedgerHQ/vanadium: Unlimited power for your apps

Unlimited power for your apps. Contribute to LedgerHQ/vanadium development by creating an account on GitHub.

Here are the slides for my talk at @BTC Prague /dev/hack/day:

Google Docs

Teach yourself HW programming

Salvatore Ingala @salvatoshi MINUTES HARDWARE WALLET PROGRAMMING It has never been this easy! COMPLETE APP BUILDING TOOLKIT “THE ULTIMATE SELF-SO...

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!

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 @The Bitcoin Conference 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 @The Bitcoin Conference in Vegas and let's keep the ball rolling.