This week’s newsletter describes a new proposal for a covenant opcode and summarizes a request for feedback on implementing regular reorgs on signet. Also included are our regular sections with ideas for preparing for taproot activation, a list of new releases and release candidates, and descriptions of popular Bitcoin infrastructure software.

News

• ● Covenant opcode proposal: Anthony Towns posted to the Bitcoin-Dev mailing list the overview of an idea for a covenant opcode, plus a more technically detailed message describing how the opcode (and some other tapscript changes) would work.

  In short, a new OP_TAPLEAF_UPDATE_VERIFY opcode (TLUV) takes information about the taproot input being spent, makes modifications described in a tapscript, and requires that the result be equivalent to the scriptPubKey in the output in the same position as the input. This allows TLUV to constrain where the bitcoins can be spent (the definition of a covenant), similar to other proposed opcodes such as OP_CHECKSIGFROMSTACK (CSFS) and OP_CHECKTEMPLATEVERIFY (CTV). Where it differs from previous proposals are the modifications it allows the creator of the tapscript to make:

  • ● Internal key tweak: every taproot address commits to an internal key that can be used to spend with just a signature. In order to use a tapscript (including TLUV), the current internal key needs to be revealed. TLUV allows specifying a tweak to be added to that key. For example, if the internal key is an aggregation of keys A+B+C, key C can be removed by specifying a tweak of -C or key X can be added by specifying a tweak of X. TLUV computes the modified internal key and ensures that is what the same-position output will pay.

    One powerful use of this described in Towns’s email is the ability to more effectively create a joinpool, a single UTXO shared by multiple users who each control a portion of the UTXO’s funds but don’t have to reveal that ownership publicly onchain (nor reveal how many owners the UTXO has). If all pool members sign together, they can spend their funds in highly fungible transactions. If there’s any disagreement, each pool member can use a transaction to exit the pool with all their funds (minus an onchain transaction fee).

    It’s possible to create a joinpool using just presigned transactions today, but this requires creating an exponentially increasing number of signatures if we want each member of the pool to be able to leave individually without the cooperation of the other members. CTV has a similar problem where exiting a pool might require creating multiple transactions that affect multiple other users. TLUV allows any single member to exit at any time without requiring anything be presigned or affecting any other users, beyond revealing that one member has left the joinpool.

  • ● Merkle tree tweak: taproot addresses can also commit to the merkle root for a tree of tapscripts, and it’ll be one of those tapscripts in the transaction input that will be executing the TLUV opcode. TLUV allows that script to specify how that part of the merkle tree should be modified. For example, the currently executed node (tapleaf) can be removed from the tree (e.g. someone exiting a joinpool) or replaced with a tapleaf paying a different tapscript. TLUV computes the modified merkle root and ensures that is what the same-position output will pay.

    Towns’s email describes how this can be used to implement Bryan Bishop’s 2019 vault design (see Newsletter #59). Alice creates two keypairs, one for her less secure hot wallet and one for her more secure cold wallet. The cold wallet key becomes the taproot internal key, allowing it to spend the funds any time. The hot wallet key is used with TLUV to only allow spending to a modification of the merkle tree that includes a time delay before a second spend from the hot wallet key may be sent.

    That means Alice can start a spend of all her funds with her hot key, but she has to create an onchain transaction for that and then wait for the time delay (e.g. 1 day) to complete before she can truly spend her funds to an arbitrary address. If someone else is using Alice’s hot key to start the spending process, Alice can use her cold key to move the funds to a safe address.

  • ● Amount introspection: in addition to TLUV, a second opcode would be added that pushes to the script execution stack the bitcoin value of the input and its corresponding output. This allows math and comparison opcodes to restrict the amount that can be spent.

    In the case of a joinpool, this would be used to ensure a departing member could only withdraw their own funds. In a vault, this could be used to set a periodic withdrawal limit, e.g. 1 BTC per day.

  As of this writing, the proposal was still receiving initial feedback on the mailing list. We’ll summarize any notable comments in a future newsletter.

• ● Signet reorg discussion: developer 0xB10C posted a proposal to the Bitcoin-Dev mailing list for creating periodic block chain reorganizations (reorgs) on signet. The blocks that would be eventually reorged would signal on one of the version field’s bits, allowing anyone who didn’t want to track reorgs to ignore those blocks. Reorgs would occur periodically, perhaps about three times a day, and would follow two different patterns that replicated what possible reorgs on mainnet would look like.

  0xB10C requested feedback and received several comments as of this writing. We encourage anyone interested in testing reorgs (or wanting to avoid them) on signet to read the discussion and consider participating.

Preparing for taproot #13: Backup and security schemes

A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

In last week’s column, Antoine Poinsot described how taproot can make vault-style coin backup and security schemes more private and fee efficient. In this week’s column, we’ll look at several other backup and security schemes that are improved by converting to taproot.

• Simple 2-of-3: as mentioned in a previous week, it’s easy to use a combination of multisignatures and scriptpath spends to create a 2-of-3 spending policy that’s normally just as efficient onchain as a single-sig spend and which is much more private than current P2SH and P2WSH multisigs. It’s still fairly efficient and private in the abnormal cases as well. This makes taproot great for upgrading your security from a single-signer wallet to a multi-signer policy.

  We expect future techniques for threshold signatures to further improve 2-of-3 and other k-of-n cases.

• Degrading multisignatures: one of the exercises in the Optech Taproot Workshop allows you to experiment with creating a taproot script that can be spent at any time by three keys, or after three days with two of the original keys, or after ten days with only one of the original keys. (That exercise also uses backup keys, but we’ll cover that separately in the next point.) Tweaking the time parameters and the key settings provides you with a flexible and powerful backup construct.

  For example, imagine you can normally spend using a combination of your laptop, mobile phone, and a hardware signing device. If one of those becomes unavailable, you can wait a month to be able to spend with the remaining two devices. If two devices become unavailable, you can spend using just one after six months.

  In the normal case of using all three devices, your onchain script is maximally efficient and private. In the other cases, it’s a bit less efficient but may still be reasonably private (your script and its tree depth will look similar to the scripts and depths used in many other contracts).

• Social recovery for backups and security: the example above is great at protecting you if one of your devices gets stolen by an attacker, but what happens if two of your devices are stolen? Also, if you frequently use your wallet, do you really want to wait even a month before you can start spending again after losing a device?

  Taproot makes it easy, cheap, and private to add a social element to your backups. In addition to the scripts in the previous example, you can also allow immediate spending of your bitcoins with two of your devices plus signatures from two of your friends or family members. Or immediate spending with only a single one of your keys plus signatures from five people you trust. (A similar non-social version of this would simply be using extra devices or seed phrases you have stored in secure locations.)

• Combining time and social thresholds for inheritance: combining the techniques above, you can allow someone or a group of people to recover your funds in case you suddenly die or become incapacitated. For example, if you haven’t moved your bitcoins for six months, you can allow your lawyer and any three of your five most trusted relatives to spend your coins. If you normally move your bitcoins every six months anyway, this inheritance preparation has no added onchain cost for as long as you live and is completely private from outside observers. You can even keep the transactions you make private from your lawyer and family as long as you have a reliable way for them to learn your wallet’s extended public key (xpub) after your death.

  Please note that making it possible for your heirs’ to spend your bitcoins doesn’t mean that they’ll be able to spend those coins legally. We recommend that anyone planning to pass on Bitcoins read Cryptoasset Inheritance Planning by Pamela Morgan (physical book and DRM’d ebook or DRM-free ebook) and use its information to discuss details with a local expert in estate planning.

• Compromise detection: an idea proposed prior to the invention of taproot is to put a key controlling some amount of bitcoin on all of the devices you care about as a way of detecting when the device has been compromised. If the amount of bitcoin is large enough, the attacker will probably spend it to themselves for the immediate gain rather than wait to use their illicit access in a long-term attack that might cause you more overall harm.

  A problem with this approach is that you want to make the amount of bitcoin offered large enough to entice the attacker but you don’t want to put large amounts of bitcoin on every one of your devices—you’d prefer to offer only one large bounty. However, if you were to put the same key on every device, the attacker transaction spending the bitcoin wouldn’t reveal which device was compromised. Taproot makes it easy to put a different key with a different scriptpath on every device. Any one of those keys will be able to spend all the funds controlled by that address, but it can also uniquely identify to you which device was compromised.

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.

• ● Bitcoin Core 22.0 is the release of the next major version of this full node implementation and its associated wallet and other software. Major changes in this new version include support for I2P connections, removal of support for version 2 Tor connections, and enhanced support for hardware wallets. Note that the release verification instructions have changed for this release, as mentioned in Newsletter #162.

• ● BTCPay Server 1.2.3 is a release that fixes three cross-site scripting (XSS) vulnerabilities that were responsibly reported.

• ● Bitcoin Core 0.21.2rc2 is a release candidate for a maintenance version of Bitcoin Core. It contains several bug fixes and small improvements.

Notable code and documentation changes

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

• ● Bitcoin Core #22079 adds IPv6 support to the ZMQ interface.

• ● C-Lightning #4599 implements the quick-close fee negotiation protocol described in BOLTs #843. We described the protocol in last week’s newsletter but our description of the existing protocol it replaced was inaccurate. The old protocol required trial and error based negotiation over what feerate to use for a mutual close transaction, and did not allow setting a feerate higher than the current commitment transaction feerate. This doesn’t make sense with anchor outputs, where low-feerate commitment transactions are designed to be fee bumped if they get used. The new protocol allows paying higher fees and uses a more efficient range-based negotiation when possible. Eclair #1768, also merged this week, implements the protocol as well.

• ● Eclair #1930 allows its path finding algorithm to be run with non-default, experimental parameter sets. This can either be done automatically for a certain percentage of traffic or manually via the API. Metrics are recorded separately for each experimental parameter set and can be used to optimize for the best path finding parameters.

• ● Eclair #1936 allows disabling the publication of a node’s Tor onion services address for cases where the user wants to keep that address private.

• ● LND #5356 adds a BatchChannelOpen RPC that can open multiple channels to different nodes in the same batched onchain transaction.

• ● BTCPay server #2830 adds support for creating a taproot-enabled wallet that can both receive and send single-sig P2TR payments, as tested on signet. An additional merged PR, #2837, lists the P2TR address support in the wallet settings but makes it unselectable until block 709,632.