Original Title: "Bitcoin Optech Newsletter #277"

Original Author: Bitcoin Optech

Translated by: Luccy, BlockBeats

Editor's Note:

The Bitcoin Operations Technology Group (Optech) is committed to bringing the best open source technology to businesses using Bitcoin, reducing costs and improving customer experience. The Bitcoin Optech Newsletter project is updated weekly and aims to record updates to Bitcoin ecosystem projects.

Newsletter #277 records adjustments to the brief anchor proposal aimed at eliminating tampering in transactions. The proposal allows transactions to contain zero-value outputs and outputs scripts that anyone can spend, making it more convenient to increase CPFP fees.

In addition, the article mentions the development of Miniscript, from its initial application in Revault to its integration into Bitcoin Core, and its support by signed device manufacturers. Miniscript is used for static analysis, composition, and general signing, providing a powerful tool for solving engineering problems for Revault. With the support of signed device manufacturers and the activation of Taproot, the future of Miniscript is promising, providing more convenient tools for contracts on Bitcoin.

This week's newsletter introduced updates to the proposal for ephemeral anchors and provided a contribution field report on Miniscript from Wizardsardine developers. It also includes regular content, announcing new software releases and release candidates, and summarizing significant changes to popular Bitcoin infrastructure projects.

News

Eliminating the tamperability of the temporary anchor point spend: Gregory Sanders proposed an adjustment to the temporary anchor point proposal on the Delving Bitcoin forum. The proposal allows transactions to contain a zero-value output and an output script that anyone can spend. Since anyone can spend the output, anyone can use CPFP fees to create transactions that increase the output. This is very convenient for multi-party contract protocols (such as LN) because transactions are often signed before the exact rate to be paid is accurately predicted. The temporary anchor point allows any party to the contract to add the fees they deem necessary. If any other party or user wants to add higher fees for any reason, they can replace the original CPFP fee increase with their own higher fee rate CPFP fee increase.

It is recommended to use a type of spend script that consists of outputs scripts equivalent to OP_TRUE, which can be spent by inputs with empty scripts. As Sanders pointed out this week, using traditional output scripts means that the child transactions it spends have tamperable txids. For example, any miner can add data to the input script to change the txid of the child transaction. This may make using child transactions unwise, as even if confirmed, it may result in a different txid that invalidates any grandchild transactions, in addition to increasing fees.

Sanders suggests using one of the output scripts preserved for future segwit upgrades. Although this will slightly increase block space, it is four bytes for segwit and one byte for OP_TRUE, but it eliminates all concerns about transaction tampering. After some discussion on this topic, Sanders subsequently proposed two points: one for an OP_TRUE version that is suitable for those who do not care about tampering and want to minimize transaction size, and one for a segwit version that is slightly larger but does not allow sub-transactions to change. Other discussions in the topic focus on selecting additional bytes for the segwit method to create a memorable bech32m address.

Domain Report: Journey of Miniscript

Our interest in Miniscript began in early 2020 when we were designing Revault, a multi-party insurance vault architecture that only uses the available script primitives at the time.

Initially, we presented Revault with a fixed set of participants. When we tried to expand it to more participants in a production environment, we quickly encountered problems.

Actually, do we suspect that the script we used in the demonstration is secure? Can it spend in all the ways it claims to? Besides these advertised ways, are there other ways to spend?

Even so, how do we promote it to different participants and keep it secure? How do we make some optimizations and ensure that the generated scripts have the same semantics?

In addition, Revault is using pre-signed transactions to enforce spend policies. How to know in advance the budget allocated for fee bumping based on the configuration of the script? How to ensure that any transaction spending these scripts passes the most common standard checks?

Finally, even if we assume that our script conforms to the expected semantics and is always spendable, how do we actually spend them? In other words, how do we generate satisfactory witnesses ("signatures") for each possible configuration? How do we make hardware signing devices compatible with our script?

If there were no Miniscript, these issues would have been a hindrance. The two people in the garage would not be able to write software that can create temporary scripts, and most importantly, call it a Bitcoin wallet that enhances security. We want to create a company around the development of Revault, but without being able to provide investors with a valid guarantee that we can launch secure products, we will not be able to obtain funding. Without funding, we will not be able to solve all these engineering problems.

Miniscript was born as "a structured way to write (Bitcoin script subset) language, supporting analysis, composition, and general signatures. It has a structure that allows for composition. Static analysis of various properties (spend conditions, correctness, security properties, tamperability, etc.) is very easy." This is exactly what we need. With this powerful tool, we can provide better guarantees to our investors, raise funds, and start developing Revault.

At the time, Miniscript had a long way to go before becoming a plug-and-play solution available to any Bitcoin application developer. (If you are a new Bitcoin developer reading this article after 2023, know that we used to have to write Bitcoin scripts by hand.) We had to integrate Miniscript into Bitcoin Core (see PRs #24147, #24148, and #24149), use it as the backend for the Revault wallet, and convince signature device manufacturers to implement it in their firmware. The latter turned out to be the most difficult part.

This is a chicken-and-egg problem: manufacturers have lower motivation to implement Miniscript without user demand, and without support for signature devices, we cannot release Revault. Fortunately, this cycle was broken in March 2021 by Stepan Snigirev, who introduced support for Miniscript descriptors to Specter DIY. However, Specter DIY was referred to as merely a "functional prototype" for a long time, until Salvatore Ingala first introduced Miniscript into the new Bitcoin application for Ledger Nano S(+) in 2022, which was released in January 2023, allowing us to launch the Liana wallet that supports the most popular signature devices.

Our Miniscript journey has one more development to go. Liana is a Bitcoin wallet focused on recovery options. It allows users to specify recovery conditions that are time-locked (such as third-party recovery keys that are typically unable to spend funds, or a gradually expanding multisig). Initially, Miniscript was only applicable to P2WSH scripts. Unfortunately, with Taproot activation nearly 2 years away, recovery paths must be published on-chain every time funds are spent. As a result, we have been working hard to port Miniscript to Tapscript.

With the implementation or ongoing implementation of Miniscript support in most signature devices (such as the recent Bitbox and Coldcard) and the continuous improvement of the Taproot and Miniscript native frameworks, it has become easier to perform contract transactions securely on Bitcoin using secure primitives.

Interestingly, the funding support for open source tools and frameworks has lowered the barrier to entry for innovative companies, thus promoting project implementation. This trend has accelerated in recent years, giving us hope for the future of this field.

Of course, there are still risks, but at least we have confidence in being able to solve some of the on-chain issues. Unexpectedly, the off-chain part proves to be more challenging.

Version Release and Candidate Versions

Here are some new and candidate versions of popular Bitcoin infrastructure projects. Please consider upgrading to the new versions or helping test the candidate versions.

LND 0.17.1-beta is a maintenance version of this Lightning Network node implementation, including some bug fixes and minor improvements.

Bitcoin Core 26.0rc2 is the candidate version for the next major release of this primary full node implementation. There is a testing guide, as well as a scheduled Bitcoin Core PR Review Club meeting focused on testing on November 15, 2023.

Core Lightning 23.11rc1 is the candidate version for the next major release of this Lightning Network node implementation.

Code and Document Changes

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

Bitcoin Core #28207 updated the way memory pool is stored on disk (usually happens during node shutdown, but can also be triggered via savemempool RPC). Previously, it was stored in a simple serialized form of basic data. Now, the serialization structure is XORed with a randomly generated value unique to each node to obfuscate the data. The same value is used to XOR during loading to eliminate the obfuscation. Obfuscation prevents someone from inserting certain data into transactions to make specific byte sequences appear in the saved memory pool data, which could cause virus scanners and other programs to flag the saved memory pool data as dangerous. The same method has previously been applied to store the UTXO set in PR #6650. Any software that needs to read memory pool data from disk should be able to easily apply the XOR operation itself or use the configuration setting -persistmempoolv1 to request saving in an unobfuscated format. Note that backward-compatible configuration settings are planned to be removed in future versions.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia