This week’s newsletter summarizes a discussion about the minimum change to Bitcoin’s Script language necessary to enable recursive covenants, examines a revised proposal to add an OP_TX opcode, and reviews research into adapting output script descriptors for hardware signing devices. Also included are our regular sections with the summary of recent changes to Bitcoin services and clients, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software. Additionally, we celebrate the publication of Optech’s 200th regular newsletter.

News

  • ● When would enabling OP_CAT allow recursive covenants? in a discussion on the Bitcoin-Dev mailing list about re-adding the OP_CAT opcode removed from Bitcoin in 2010, developer ZmnSCPxj claimed OP_CAT needed to be combined with proposed opcodes OP_TX (see Newsletter #187), OP_CHECKSIGFROMSTACK (CSFS), or a similar feature in order for it to enable inescapable recursive covenants—contracts which use Bitcoin’s consensus rules to enforce that all bitcoins received to the contract can only be spent to the same contract.

    Recursive covenants depend on a technique referred to as transaction introspection by which an opcode can analyze part of the transaction which executes that opcode. Existing opcodes OP_CHECKSIG, BIP65 OP_CHECKLOCKTIMEVERIFY, and BIP112 OP_CHECKSEQUENCEVERIFY provide limited introspection. Proposed opcodes TX and CSFS could allow flexible introspection of all parts of a transaction, including its next output (the amount of bitcoins and the address that’s being paid) and its prevout (previous output, the amount of bitcoins previously received and the script currently being used to authorize their spending).

    If an opcode or other script feature is used to ensure the prevout and next output are identical, the simplest type of recursive covenant is created. However, prevouts aren’t directly part of transactions—they must be obtained from the block chain—so a copy of a prevout must be included in a transaction in order to compare a prevout to the next output. Adding even more complication, the use of hash functions in multiple parts of Bitcoin transactions seems to prevent a prevout script from being able to directly compare itself to the next output script; instead, either the prevout, next output, or both must be dynamically constructed from their constituent elements—this is what makes the proposed concatenation opcode (CAT) or a similar construct necessary for recursive covenants.

    In many cases, the most efficient way prior to taproot to include a copy of a prevout in a transaction was for it to be provided as authorization data similar to a digital signature. If the copy of the prevout is provided alongside a signature, it can be checked by introspection of the transaction witness, which would require a flexible introspection facility such as TX or CSFS. The proposed CTV and APO script changes would also allow introspection of a next output, but they’re much less able to introspect a witness, making it appear that they were unable to create recursive covenants even when combined with CAT.

    Nadav Ivgi replied that it’s also possible to include a copy of the information used to construct the prevout in the prevout itself (by adding that information when it’s the next output). When creating recursive covenants, this still requires CAT to get around problems with hashing, but it means features such as CTV and APO that focus on output introspection are also able to create recursive covenants in combination with CAT. When used with the features of taproot, Ivgi also thinks verifying prevouts through next outputs makes covenant scripts simpler to write and he provides links to two interesting example recursive covenants.

    ZmnSCPxj agreed with Ivgi’s analysis and echoed his previous concern about the risk of enabling recursive covenants on Bitcoin (see Newsletter #190), although he also noted in a subsequent post that “[for what it’s worth], recursive covenants are probably safe, as they are not in fact Turing-complete”.

    Russell O’Connor also cited a post by Andrew Poelstra (covered in Newsletter #134) describing how CAT by itself is powerful enough in combination with already-available Bitcoin features to create non-recursive covenants—and, more theoretically, might also be able to create recursive covenants by itself if it was added back into Bitcoin.

    All of the discussion was about proposed additions to Bitcoin, so there are no changes to our understanding of the currently-deployed state of the Bitcoin system.

  • ● Updated OP_TX proposal: as described in Newsletter #187, Rusty Russell proposed an OP_TX opcode (based on previous proposals) that would allow a tapscript to push to the stack selected parts of the transaction executing it. For example, Alice could receive bitcoins to a script containing OP_TX(SELECT_LOCKTIME) to push the locktime of the spending transaction onto the stack. Using this generic transaction introspection feature of TX, Alice could then replicate the specific introspection capability of OP_CHECKLOCKTIMEVERIFY (CLTV), e.g. OP_TX(SELECT_LOCKTIME) <height> OP_GREATERTHAN OP_VERIFY.

    Using CLTV in the above example case would use fewer vbytes than TX, but TX’s flexibility could allow examining many other parts of a transaction that currently can’t be introspected in Bitcoin. TX could also possibly introspect data that’s outside of a transaction but which is needed by full nodes in order to validate that transaction. As originally proposed, TX was flagged for enabling recursive covenants, which currently appear to be controversial (see Newsletter #190).

    This week, Russell proposed a restricted version of TX that only provides access to the same fields as used by OP_CHECKTEMPLATEVERIFY (CTV) and only in the same hash digest format that CTV consumes. BIP119 CTV was specifically designed not to create recursive covenants in combination with any existing Script features, so the restricted TX opcode should provide all the same features while also not enabling recursive covenants.

    Additionally the restricted TX is designed so that future soft forks could easily extend it with additional introspection features, including optionally features that enable recursive covenants if there was support for adding that capability. As of this writing, two developers suggested uses for TX by extending it with slightly more features:

    • ● Improved vault primitive: Russell’s proposal suggests an extension that would provide the ability to push onto the stack the number of satoshis being spent to each output in the transaction. Brandon Black suggests that also including the amount of each prevout (input) being spent would make it easier to create vaults. Black in particular suggests replicating the capability of the OP_IN_OUT_AMOUNT opcode from the OP_TAPLEAF_UPDATE_VERIFY (TLUV) proposal several months ago (see Newsletter #166).

    • ● Using transaction introspection to prevent RBF pinning: Gregory Sanders noted that the proposed Eltoo layer for LN which makes use of the SIGHASH_ANYPREVOUT opcode may be vulnerable to transaction pinning attacks as an interaction with BIP125 rule #3 (see Newsletter #27). Sanders suggests that giving TX the ability to push the transaction weight (size) to the stack would allow the participants in an eltoo-based payment channel to put a limit on the maximum size of a transaction, eliminating as a risk one type of pinning that depends on inflating the size of a transaction. This seems conceptually similar to an idea mentioned in Newsletter #191 for preventing CPFP pinning.

  • ● Adapting miniscript and output script descriptors for hardware signing devices: Salvatore Ingala posted to the Bitcoin-Dev mailing list about his work implementing output script descriptors (descriptors) and miniscript for hardware signing devices. He noted that signing devices are particularly focused on policy verification—users need to understand what will happen if they approve a transaction but they shouldn’t be prompted for more information than necessary to ensure their funds are safe. Due to the small screen size on many signing devices and the difficulty verifying information there, it’s also important to display information as compactly as possible. Ingala suggests several enhancements to descriptors to address these problems:

    • ● Policy registration: during the setup of a signing device, the user should use the device to validate their preferred policy. For devices with persistent storage, the registered policy should be saved to the device. For devices without storage, the device should return a cryptographically secure proof of registration that may be quickly reloaded along with the policy each time the device is started. The proposal doesn’t describe the details of how policies should be registered on devices, but it does reference BIP129 secure multisig setup (see Newsletter #136).

    • ● Key placeholders: instead of including repeated BIP32 extended keys in descriptors, Ingala suggests allowing policy to define a short placeholder that will be replaced with BIP32 information when the policy is interpreted. This can both significantly reduce the byte size of policies and also make them much more human readable. Ingala also suggests a few shortcuts for commonly used strings in descriptors.

    • ● Reduced expressiveness: only a subset of descriptors is supported, although additional features may be added later if there is desire for them. This simplifies implementation.

    The proposal received some discussion on the mailing list as of this writing.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

  • ● MyCitadel Wallet released: MyCitadel Wallet is a desktop Bitcoin, Lightning, and RGB wallet application supporting multisig, PSBTs, segwit, taproot, timelocks, hardware signing devices, descriptors, and other features.

  • ● Tauros exchange supports Lightning: Mexican exchange Tauros announces Lightning deposit and withdraw support.

  • ● Lightning Multiplexer announced: The Lightning Multiplexer (lnmux) software, supporting LND, improves Lightning payment reliability by allowing for fail-over scenarios for incoming payments. More details are available on the Bottlepay blog post.

  • ● Coldcard adds taproot sends: The latest Coldcard firmware (Mk4 5.0.3, Mk3 4.1.5) support sending to bech32m addresses.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● Bitcoin Core #22235 adds a script that will generate an example bitcoin.conf file directly from the source code defining the configuration options. This change allows future Bitcoin Core releases to have a pre-installed bitcoin.conf file without creating a second source of truth on the state of configuration options.

  • ● LND #6450 adds support for signing PSBTs that spend taproot outputs.

  • ● LND #6345 allows LND to get updates about new transactions and blocks by repeatedly polling Bitcoin Core rather than receiving push updates from it via ZMQ.

  • ● BIPs #1309 updates BIP119’s example implementation of OP_CHECKTEMPLATEVERIFY. The previous example contained the code implementing the opcode for Bitcoin Core, which is written in C++. The new example is written in pseudo-python. Extra information is also added about how to avoid a potential denial-of-service attack possible in a naive implementation, addressing a concern previously discussed on the Bitcoin-Dev mailing list (see Newsletter #183).

Celebrating Optech Newsletter #200

Every fifty newsletters, we take a moment to highlight some of Optech’s major accomplishments. We do this in part to help readers learn about all we have to offer and in part to help attract donations that allow us to continue producing useful resources. But, at least a little bit, we also do it to brag.

We don’t brag out of personal vanity but because each contributor to Optech is themselves a huge fan of the other contributors. Working with amazing people as a team is a wonderful experience and these special newsletter sections are usually where we get to put into print some of our unreserved admiration for each other.

That’s not what we’re doing this year. Instead, we wanted to give you, the readers, your own chance to share some of your admiration for Optech’s contributors. Without even soliciting comments, we found dozens and then hundreds of lovely things said by our readers on Twitter. There were too many incredible comments to reasonably print, so we limited ourselves to the top 50 from the past four years.

You’ll find the comments below, but first we want to thank our main contributors from the past year—Adam Jonas, Carl Dong, David A. Harding, Gloria Zhao, John Newbery, Mark Erhardt, Mike Schmidt, and Shigeyuki Azuchi—and also thank our many supporters, including our founding sponsors Wences Casares, John Pfeffer, and Alex Morcos.

The 100th issue of @bitcoinoptech was just published. […] It’s one of the best technical newsletters in Bitcoin.

—@Bitcoin

Follow @bitcoinoptech and subscribe to the free newsletter for true signal. I don’t understand all of it, but it keeps me bullish regardless of what the market is doing.

—@ChartsBTC

Bitcoin Optech @bitcoinoptech has a great overview of what is being worked on currently in Bitcoin. It really shows how much that is actually happening in the Bitcoin space and kills the notion that Bitcoin is “stale old tech”. https://bitcoinops.org/en/topic-dates/

—@softsimon
Creator of Mempool.Space

I’d also highly recommend @bitcoinoptech :)

—Alexander Leishman
Founder, River Financial

While the consumer market grows and infrastructure advances, work to catalyze enterprise adoption of (a) protocol upgrades and (b) the techniques that allow service providers to operate more efficiently and better serve the growing market, is underway via @bitcoinoptech

—Alyse Killeen
Founding Partner, Stillmark

The Bitcoin Optech (@bitcoinoptech) newsletter continues to deliver interesting and detailed content. I just read the [latest] one and it was great.

—Andreas M. Antonopoulos
Author of Mastering Bitcoin and co-author of Mastering the Lightning Network

As always, thanks for this newsletter!

—Bastien Teinturier
VP of Engineering at ACINQ

@bitcoinoptech does a good job explaining the tech to a technical integrators audience, I would watch their workshop

—Ben Woosley
Bitcoin Core Developer and Senior Developer at Unchained Capital

Bitcoin Optech (@bitcoinoptech) was founded in 2018 to bridge the worlds of open-source development and companies. They have come a long way since inception.

—Bitcoin Magazine

Incredible roundup of all the major developments in Bitcoin and Lightning during 2018 from the excellent @bitcoinoptech newsletter. Month by month walk through with links. Makes for a nice weekend reading list!

—Buck Perley
Engineer at Unchained Capital

Another great newsletter. Thanks @bitcoinoptech !

—CardCoins

I think efforts like @bitcoinoptech are improving communication, but we need more!

—Carl Dong
Bitcoin Core developer at Chaincode Labs

Get a head start on your New Years resolution to keep up with the wonderful world of Bitcoin development by reading @bitcoinoptech’s 2021 year in review 🌟

—Carla Kirk-Cohen
Independent LN Developer and Board Member at Brink, ₿trust, and Qala

A bit behind on Taproot? There is still time and luckily for you @bitcoinoptech has a GREAT workshop that will bring you up to speed: https://github.com/bitcoinops/taproot-workshop/

Can highly recommend. It goes through all the building blocks you need. Go do iiiiiiiit 💪 #Bitcoin #taproot

—Elle Mouton
Engineer, Lightning Labs

We [at Bitcoin Magazine] do our best to distill the hard stuff, but @bitcoinoptech is pretty hard to beat if you’re looking for the raw goods.

It’s my favorite non-BM content by far and one of the few newsletters that stay in my inbox until I can actually spend proper time on it.

—Flip Abagnale

@bitcoinoptech is honestly amazing

—George Kaloudis
Research Analyst for CoinDesk

@bitcoinoptech is a great resource

—Gregory Sanders
Bitcoin Developer

Just wanted to say a thanks to the @bitcoinoptech team for their newsletter.

It saves me a TON of time going through chats and emails to just hit the main developments & easily dig deeper into anything particularly relevant or interesting.✊

—Guy Swann
Host of Bitcoin Audible

P.S. I want to appreciate developers, educators, and miners who run and improve the network every day.

Folks at @lightning, @ChaincodeLabs, @CryptoGarageInc , @Blockstream, @bitcoinoptech, and many many contributors are doing amazing things.

I really thank you all.

—Haegwan Kim

Great summary for the year 👍 @bitcoinoptech

—Hong Fang
CEO of OKCoin

Ignoramus: “Bitcoin stopped innovating; development is stalled!”

Me: “@bitcoinoptech’s annual high level review of developments won’t even fully render in my email client because it’s too long.”

—Jameson Lopp
Co-founder and CTO at Casa

one of the few newsletters I read every issue of, consistently. thanks @bitcoinoptech

—John Light
Human Rights Foundation ZK-Rollup Research Fellow

Immense admiration for the talented and passionate developers dedicated to building #bitcoin. It’s a privilege to support @meshcollider, Antoine Riard, @bitcoinoptech, @mitDCI, dev training…and more to come soon! Please join me in supporting #btc development!

—John Pfeffer
Entrepreneur and investor

Giving a shout out to Bitcoin Optech, who (among other things) chronicle technical development in Bitcoin. No hype, no drama, just great information about advances in using and deploying Bitcoin. @bitcoinoptech

—Johnathan Corgan

@bitcoinoptech topics are a good first place to start

—Jon Atack
Bitcoin Developer

@bitcoinoptech wrote a very nice year-in-review newsletter

—Justin Moon

This writeup by […] @bitcoinoptech explains why nonce reuse in a multisig setup is bad and also the challenges in avoiding it. It really helped me understand the issue better. Thanks!

—Kalle Rosenbaum
Author of Grokking Bitcoin

There’s plenty of newsletters around crypto stuff to keep you up to date.

One of the ones I’ve religiously followed has been @bitcoinoptech.

highly recommended if you hold some btc and wants to see real work being done to make the protocol better.

—Kristian Kho

Important piece by @bitcoinoptech summarizing & cataloging notable coding developments

—Leah Wald
CEO at Valkyrie Investments

Don’t you love finding amazing educational resources out of nowhere?

My #1 project this weekend will be @bitcoinoptech’s workshop on taproot, which I only recently discovered.

—Lucas Nuzzi
Head of R&D at CoinMetrics.io

Wow - @bitcoinoptech has 25+ contributors!!

The highest quality of #Bitcoin news - peer reviewed by high caliber free software contributors!

Thanks to all the supporters. 🔥🚀

—Max Hillebrand
Free Software Entrepreneur

I’m assuming everyone knows about the excellent @bitcoinoptech newsletter by now. But did you know it has a topics page indexed by topic name, event and part of Bitcoin system it impacts? https://bitcoinops.org/en/topic-categories/

—Michael Folkson

Thanks to everyone who helped us get here: co-authors @ajtowns, @n1ckler, and @real_or_random, everyone who contributed to the document, the participants in the @bitcoinoptech workshops and structured review, Greg Maxwell for the original idea, and many others.

—Pieter Wuille
Bitcoin Developer at Chaincode Labs

[…] it’s almost a full time job trying to summarise what’s happening everywhere. That’s what guys at @bitcoinoptech does, so just following their news letters will give good enough understandings.

—Rajarshi Maitra

Once again I enjoyed @bitcoinoptech newsletter […] This is the most informative and best resource and overview for developers and educators.

—Rene Pickhardt
Bitcoin and Lightning Network Developer

I recommend the video series from @bitcoinoptech for understanding Taproot, in particular the interactive colab notebook from @digi_james is very helpful for understanding how to use tapscript.

—Richard Myers

The @bitcoinoptech newsletter presents cutting-edge developments and updates in #Bitcoin each week.

—River Financial

@bitcoinoptech is an incredibly valuable community project and the greater the percentage of the wider ecosystem that is involved and learning best practices, the better

—Robert Spigler
OpSec consultant

Follow @bitcoinoptech and sign up for their news letter, 5-9 signal.

Very few sources of bitcoin technical information are this well summarized and explained.

Do it now, so that you don’t forget 😉

—Rodolfo Novak
CEO and Co-Founder of Coinkite

As always, @bitcoinoptech provides an expertly crafted summary […]

—Ruben Somsen
Bitcoin Sorcerer and co-host of The Unhashed Podcast

trying to read less twitter and more @bitcoinoptech

—Sahil Chaturvedi
Product Designer at Unchained Capital

A great example of why Game Theory is so important, in the latest edition of @bitcoinoptech

—Sam Wouters
Bitcoin Educator

Great work to the @bitcoinoptech team on a comprehensive job well done with the compatibility matrix.

—Samourai Wallet

Nice write up @bitcoinoptech. 👍

—Samson Mow
CEO of Jan3

The taproot series has been an invaluable resource for understanding not only the big picture, but also the technical details. Ty to everyone that contributed to this!

—Stacie Waleyko
Engineering at Casa

Great and perhaps less well known resource for people learning more about Bitcoin tech: [the] @bitcoinoptech topics pages: https://bitcoinops.org/en/topics/

—Stephan Livera
Managing Director at Swan Bitcoin and Podcaster

@bitcoinoptech had a nice writeup of LDK’s approach in February https://bitcoinops.org/en/newsletters/2022/02/23/#ldk-1199

—Steve Lee
Lead at Spiral

Thank you @bitcoinoptech, one of the best organizations in Bitcoin, focused on helping the rest of us use Bitcoin and be better Bitcoiners!

—Terrence Yang

Our whole team is honored to be included in the most respected and advanced technical #bitcoin newsletter that is @bitcoinoptech

—Veriphi

Really, @bitcoinoptech is essential reading material for every bitcoiner.

—Zack Voell