#136

Bitcoin Optech #153: Locking In Taproot

Satoshi Nakamoto
Jun 16, 2021
5 min read

The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter celebrates the lock-in of the taproot soft fork, describes a draft BIP for improving transaction privacy by varying the fields used to implement anti fee sniping, and features an article about the challenges of combining transaction replacement with payment batching. Also included are our regular sections with announcements of new software releases and release candidates, plus notable changes to popular Bitcoin infrastructure software.

News

Taproot locked in: the taproot soft fork and related changes specified in BIPs 340, 341, and 342 were locked in by signaling miners last weekend. Taproot will be safe to use after block 709,632, which is expected in early or mid November. The delay gives time for users to upgrade their nodes to a release (such as Bitcoin Core 0.21.1 or later) that will enforce taproot’s rules, ensuring that funds received to taproot scripts after block 709,632 are safe even if there’s a problem with miners.Developers are encouraged to start implementing taproot so they can be ready to take advantage of greater efficiency, privacy, and fungibility as soon as the activation is complete.Readers celebrating the lock-in of taproot may also wish to read a short thread about taproot’s origins and history by developer Pieter Wuille.
BIP proposed for wallets to set nSequence by default on taproot transactions: Chris Belcher posted a draft BIP to the Bitcoin-Dev mailing list suggesting an alternative way wallets can implement anti fee sniping. The alternative method would enhance the privacy and fungibility of transactions made by single-sig users, multisignature users, and users of certain contract protocols such as taproot-enabled LN or advanced coinswaps.Anti fee sniping is a technique some wallets implement to discourage miners from trying to steal fees from each other in a way that would reduce the amount of proof of work expended on securing Bitcoin and limit users’ ability to rely on confirmation scores. All wallets that implement anti fee sniping today use nLockTime height locks, but it’s also possible to implement the same protection using BIP68 nSequence height locks. This wouldn’t be any more effective at preventing fee sniping, but it would provide a good reason for regular wallets to set their nSequence values to the same values that are required for transactions in certain multisignature-based contract protocols, such as ideas for coinswaps and taproot-enabled LN. This helps make regular wallet transactions look like contract protocol transactions and vice versa.Belcher’s proposal suggests wallets randomly choose between using either nLockTime or nSequence with 50% probability when both options are available. Overall, if the proposal is implemented, it will allow users of regular single-sig transactions or uncomplicated multisignatures to join together with users of contract protocols to mutually improve each others’ privacy and fungibility.

Field Report: Using RBF and Additive Batching

by CardCoins

“Additive batching” is a scheme in which additional outputs are added to unconfirmed transactions in the mempool. This field report outlines efforts CardCoins has taken in introducing a reorg- and DoS-safe implementation of such a scheme in its customer payout workflow.

Replace By Fee (RBF, BIP125) and batching are two important tools for any enterprises directly interacting with Bitcoin’s mempool. Fees go up, fees go down, but the business must always fight for fee efficiency.

Each tool, while powerful, has its own complexities and nuances. For example, batching customer withdrawals may save on fees for the enterprise, but will likely make child pays for parent (CPFP) uneconomical for a customer who wishes to speed up the transaction. Similarly, RBF is useful for an enterprise who takes a fee-underbidding strategy (their initial transaction broadcast starts at a low fee, and is slowly bid upwards), but it exposes their customers to potential confusion as their withdrawal transaction updates in their wallet. It would also be messy for the customer to spend from this transaction while it remains unconfirmed, as the enterprise will have to pay for this child spend when attempting to replace the parent. Even worse, the enterprise may have a withdrawal pinned by another service which received the customer’s withdrawal.

When combining these two tools, a service provider unlocks new functionality but is similarly exposed to novel forms of complexity. In the base case, combining RBF and a single, static batch carries a simple combination of the complexities that RBF and batching carry discretely. However, when you combine RBF and “additive batching,” emergent edge cases and dangerous failure scenarios present themselves.

In additive RBF batching, the service provider introduces new outputs (and confirmed inputs) to a transaction in the mempool to incorporate new customer withdrawals into an unconfirmed transaction. This enables the service provider to give users the experience of an instantaneous withdrawal while still retaining much of the fee savings from doing large batches of customer withdrawals at once. As each customer requests a withdrawal, an output is added to the transaction in the mempool. This transaction continues to be updated until it confirms or reaches some other local optimum.

There are many strategies to this type of additive RBF batching. At CardCoins we took a safety-first approach to our implementation (with the help of Matthew Zipkin), the details of which we described in a blog post, RBF Batching at CardCoins: Diving into the Mempool’s Dark Reorg Forest.

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.

Rust Bitcoin 0.26.2 is the project’s latest minor release. Compared to the previous major version, it contains several API improvements and bug fixes. See the changelog for details.
Rust-Lightning 0.0.98 is a minor release containing several improvements and bug fixes.
LND 0.13.0-beta.rc5 is a release candidate that adds support for using a pruned Bitcoin full node, allows receiving and sending payments using Atomic MultiPath (AMP), and increases its PSBT capabilities, among other improvements and bug fixes.

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 GUI #4 adds initial support for using Hardware Wallet Interface (HWI) external signers via the GUI. Once this feature is finalized, users will be able to use their HWI-compatible hardware wallets directly from the Bitcoin Core GUI.
Bitcoin Core #21573 updates the version of libsecp256k1 included in Bitcoin Core. The most notable change is the use of the optimized modular inverse code described in Newsletters #136 and #146. Performance evaluations posted to the PR found it accelerated old block verification by about 10%.
C-Lightning #4591 adds support for parsing bech32m addresses. C-Lightning will now permit a peer that has negotiated the feature option_shutdown_anysegwit to specify any v1+ native segwit address as a closing or withdrawal destination.

Find the original post here.

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.

Bitcoin Optech #150: Libera.Chat And Celebrating 150 Editions

Satoshi Nakamoto
May 26, 2021
7 min read

This week’s newsletter announces a change of networks for several IRC channels and celebrates Optech’s 150th newsletter. Also included are our regular sections with popular questions and answers from the Bitcoin Stack Exchange, new software releases and release candidates, and notable changes to popular Bitcoin infrastructure projects.

News

IRC channels moving to Libera.Chat: in the weekly Bitcoin Core developer meeting, it was decided that the meeting on Thursday, May 27th, will be the last meeting held on the Freenode network. Bots, logging, other infrastructure, future meetings, and general discussion will be moved to #bitcoin-core-dev on the Libera.Chat network. Actions by the Freenode administrators occurring shortly before publication of this newsletter seem to have forced the move to occur early Wednesday morning (UTC). Several other channels related to Bitcoin and LN are also moving. For help finding the current network for various channels, see the Bitcoin Wiki’s list of IRC channels. If you operate a channel that’s moving and don’t have a Wiki account to update that list yourself, please let the editors know in #bitcoin-wiki on Libera.

Celebrating Optech Newsletter #150

by John Newbery, Founder, Optech

This is the 150th regular Optech weekly newsletter that we’ve written for the Bitcoin technical community. Pausing only for short breaks around the Christmas holidays, we’ve published digests of the most important events in Bitcoin and Lightning development every week since June 2018.

Optech was started with some very simple goals: to help Bitcoin businesses adopt technologies that allow Bitcoin to scale, and to highlight the amazing technical work happening in the open source Bitcoin community. Although we couldn’t foresee exactly what form that would take three years ago, it’s a mission that we continue to believe in, and that guides all the work we do. Since June 2018, we’ve:

Published 150 newsletters, numerous blog posts and field reports, a special series on bech32, and an interactive taproot workshop. In total, we’ve published around 250,000 words – enough to fill around 700 printed pages.
Reached 4,100 email subscribers and almost 11,000 twitter followers.
Started seeing some of our newsletters translated into Japanese and Spanish by members of the community.
Produced and maintained a topics index – a single location where readers can track the evolution of Bitcoin and Lightning proposals and improvements.

The newsletters are the work of many contributors. Foremost amongst them is Dave Harding, who writes the majority of our content. To say that Dave is prolific is an understatement – week after week, he produces concise, clear summaries of the enormously varied research and development happening across the Bitcoin ecosystem. We’re lucky to have someone of his breadth of knowledge, dedication and humility documenting Bitcoin. The extensive body of work that he’s produced for Optech and other projects is a huge asset for all present and future Bitcoiners.

The supporting roles are filled by other Optechers. Mike Schmidt writes our regular sections on Stack Exchange Q&As and Notable Changes to Bitcoin Software and Infrastructure, and makes sure that the newsletter arrives in everyone’s inbox on time. Jon Atack contributes our regular summary of Bitcoin Core PR Review Club. As well as Mike and Jon, Carl Dong, Adam Jonas, Mark Erhardt and I contribute occasional PR summaries and review each week’s newsletter to try to ensure the content we produce is accurate and clear.

Special thanks to Shigeyuki Azuchi, who translates our newsletters into Japanese, and Akio Nakamura who has also translated and reviewed our Japanese material.

Thanks to all the members of the Bitcoin community – too numerous to name individually – who have reviewed our newsletters, helped us understand concepts, and opened issues and PRs when we’ve made mistakes.

All of this work is made possible by our generous supporters, primarily our founding sponsors – Wences Casares, John Pfeffer and Alex Morcos.

Finally, thank you, our readers. We love being part of this community and contributing to this ecosystem. Knowing how valuable this resource is to so many people, and hearing feedback from our readers is hugely rewarding for us. If you want to contribute, or have suggestions for how we can improve, please don’t hesitate to contact us at info@bitcoinops.org.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

Why are there more than two transaction outputs in a coinbase transaction? Andrew Chow explains some common outputs in a coinbase transaction:

a single miner block reward payment

multiple payments, as with a mining pool paying miners

BIP141’s OP_RETURN witness commitment

additional OP_RETURN commitments, as in merge mining and other protocols

fundrawtransaction – what is it? Pieter Wuille illustrates what the fundrawtransaction RPC does by providing 4 examples of how to send coins using the RPC.
What previously existing technologies made Bitcoin possible? Murch provides a summary, based on the Bitcoin’s Academic Pedigree paper, of the existing technological ingredients that were combined to create Bitcoin. These technologies are linked timestamping/verifiable logs, byzantine fault tolerance, proof of work, digital cash, and public keys as identities.
How can I follow the progress of miner signaling for Taproot activation? In addition to Hampus Sjöberg’s https://taproot.watch website, Bitcoin Core users can use getblockchaininfo to get a count of signaling blocks and getblock’s versionhex field, where the signaling version bits reside, to observe signaling.

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.

Eclair 0.6.0 is a new release that with several improvements that enhance user security and privacy. It also provides compatibility with future software that may use taproot addresses.
LND 0.13.0-beta.rc3 is a release candidate that adds support for using a pruned Bitcoin full node, allows receiving and sending payments using Atomic MultiPath (AMP), and increases its PSBT capabilities, among other improvements and bug fixes.

Notable code and documentation changes

Bitcoin Core #21843 adds a network argument to the getnodeaddresses RPC. When getnodeaddresses is called with this argument set to a supported network type (ipv4, ipv6, onion or i2p), it will only return known addresses on the specified network. When called without the network argument, getnodeaddresses will return known addresses from all networks.
Eclair #1810 makes it mandatory for peers to signal and comply with the payment_secret feature bit. The payment secrets feature thwarts a recipient de-anonymization attack and provides additional protection against improper image revelation. The feature is supported across all major implementations and is mandatory for payments to LND and Rust-Lightning.
Eclair #1774 extends Java’s built-in SecureRandom() CSPRNG function with a secondary source of weaker randomness. The weaker randomness is hashed and the hash digest xored with the primary randomness so that, even if SecureRandom() produces predictable results due to some bug discovered in the future, there’s a chance Eclair will continue to have enough entropy so that its cryptographic operations remain unexploitable.
BIPs #1089 assigns BIP87 to a proposal previously discussed on the mailing list for creating a standardized set of BIP32 paths for multisig wallets regardless of their multisig parameters, what address type they use, or other script-level details. Instead, users of the proposed standard store those details in an output script descriptor. This eliminates the need for wallets to implement multiple different standards for slight variations on multisig (e.g. BIP45 and the m/48′ standard) or create new standards for things that can be handled by descriptors. Although using a descriptor rather than a standardized script does mean more data needs to be backed up, the actual difference is small—most of the data in a typical multisig descriptor will be the extended public keys (xpubs) that need to be backed up by each party to a multisig anyway, so the additional information about the script template and the descriptor’s checksum only add a small amount of overhead by comparison.
BIPs #1025 assigns BIP88 to the standardized format described in Newsletter #105 for describing what BIP32 key derivation paths a wallet should support. Path templates provide a compact way for the user to specify which paths they want to use. The compactness of path templates makes it easy to back up the template along with the seed, helping prevent users from losing funds. An additional feature of the proposed path templates is the ability to describe derivation limits (e.g. that a wallet should derive no more than 50,000 keys in a particular path), which can make it practical for a recovery procedure to scan for bitcoins received to all possible wallet keys, eliminating concerns about gap limits in HD wallets.
BIPs #1097 assigns BIP129 to the Bitcoin Secure Multisig Setup (BSMS) described in Newsletter #136, which explains how wallets, particularly hardware signing devices, can securely exchange the information necessary to become signers for a multisig wallet. The information that needs to be exchanged includes the script template to use (e.g. P2WSH with 2-of-3 keys required to sign) and each signer’s BIP32 extended public key (xpub) at the key path it plans to use for signing. The protocol uses a coordinator to collect the required information and create an output script descriptor, which the individual signers then verify to ensure it properly includes their key.

Find the original post here.

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.

Bitcoin Optech #146: Splicing, Workshop Announcements And More

Satoshi Nakamoto
Apr 28, 2021
6 min read

This week’s newsletter describes a draft specification for LN splicing, announces a workshop about transaction relay security, announces the addition of ECDSA signature adaptor support to libsecp256k1-zkp, and links to proposals to change the BIPs process. Also included are our regular sections with summaries of popular questions and answers from the Bitcoin StackExchange, announcements of software releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.

News

Draft specification for LN splicing: Rusty Russell opened a PR to the Lightning Specifications repository (“BOLTs”) proposing the protocol changes necessary to accommodate splicing. He also posted a link for the PR to the Lightning-Dev mailing list. Splicing will allow transferring funds from onchain outputs into an existing payment channel, or from an existing payment channel to independent onchain outputs, without the channel participants having to wait for a confirmation delay to spend the channel’s other funds. This helps wallets hide from their users the technical details of managing balances. For example, Alice’s wallet can automatically pay Bob offchain or onchain from the same payment channel—offchain using LN through that payment channel or onchain using a splice out (withdrawal) from that payment channel.Russell previously proposed a draft specification for splicing in 2018 (see Newsletter #17) but this new draft has the advantage of being able to use the interactive funding protocol that’s included as part of C-Lightning’s experimental support for dual funding.
Call for topics in layer-crossing workshop: Antoine Riard posted to both the Bitcoin-Dev and Lightning-Dev mailing lists about an upcoming IRC-based workshop he plans to host to discuss challenges with onchain transaction relay that affect layer-two protocols such as LN. The goal is to build technical consensus among the participants about which proposals are especially worth perusing so that developers and reviewers can focus on those proposals in the short term.The post proposes an agenda that includes package relay, fee sponsorship (see Newsletter #116), moving from BIP125 opt-in Replace By Fee (RBF) to full RBF, improving coordination of security response between primarily onchain projects such as full nodes and primarily offchain projects like LN nodes, and defining what mempool and relay policies can be reasonably depended upon by layer two protocols. Riard also asks for additional topic suggestions from anyone planning to attend, with May 7th being the deadline for submissions. The workshop will likely be held mid June.
Support for ECDSA signature adaptors added to libsecp256k1-zkp: signature adaptors were originally described for Bitcoin by Andrew Poelstra using schnorr-based multisignatures. This allows a single signature to do up to three things at once: (1) prove its creator had access to a certain private key, (2) prove knowledge of an encryption key pre-selected by another party, (3) reveal a pre-selected encryption key to another party. This allows a signature alone to do many of the things we currently do with Bitcoin scripts, suggesting adaptor signatures could be used to create “scriptless scripts”.Accomplishing the same on ECDSA is not as easy. However, Lloyd Fournier suggested it would be relatively simple if we separated goal #1 (proof of private key) from goals #2 and #3 (proving and revealing encryption keys, AKA adaptors). This requires using one signature object as just a signature and another signature object for the adaptors, so it uses OP_CHECKMULTISIG and is not quite as scriptless as before. The separated construction also requires a security warning related to reusing some of the involved keys with Elliptic Curve Diffie Hellman (ECDH) key exchange and ElGamal encryption. Beyond that, this technique makes signature adaptors entirely usable on Bitcoin today, and it’s what various DLC projects have been using.In April 2020, Jonas Nick implemented support for these simplified ECDSA signature adaptors in a draft PR (see Newsletter #92). Jesse Posner ported and extended the PR to libsecp256k1-zkp, a fork of libsecp256k1 that supports more advanced cryptographic protocols. This updated PR has now been merged after a detailed review process that involved several conversations that may be of interest to anyone seeking to better understand the security of signature adaptors.
Problems with the BIPs process: after some drama on the BIPs repository (and perhaps some previous pent-up frustrations), several discussions were started on the mailing list about adding a new BIPs editor, using a bot to merge BIPs PRs, or abandoning the centralized BIPs repository altogether.

Selected Q&A from Bitcoin StackExchange

Bitcoin StackExchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

What are the different contexts where MTP is used in Bitcoin? David A. Harding defines Median Time Past (MTP) and outlines how MTP is used to:

determine the validity of a block using its nTime field, controlling difficulty adjustment period times

ensure that time only moves forward, simplifying state transitions in BIP9

eliminate the incentive for individual miners to confirm transactions with locktimes up to two hours in the future by lying about the current time, as fixed in BIP113

Can Taproot be used to commit arbitrary data to chain without any additional footprint? Pieter Wuille answers by pointing out that while committing to data via OP_RETURN in a tapleaf is possible, techniques like pay-to-contract and sign-to-contract are in use currently by Liquid and OpenTimestamps and can be more efficient.
Why does the mined block differ so much from the block template? User Andy asks why block 680175 differs from what his getblocktemplate RPC had output around the same time that block was mined. Andrew Chow and Murch point out Asicboost as the reason the version field is different, while node-independent mempools and node uptime are considerations of the block’s transaction discrepancies.
Isn’t Bitcoin’s hash target supposed to be a power of 2? Andrew Chow explains the ‘leading zeros’ explanation of difficulty targeting is an oversimplification and chytrik gives an example of a valid and invalid hash with the same number of leading zeros.

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 0.21.1rc1 is a release candidate for a version of Bitcoin Core that contains activation logic for the proposed taproot soft fork. Taproot uses schnorr signatures and allows the use of tapscript. These are, respectively, specified by BIPs 341, 340, and 342. Also included is the ability to pay bech32m addresses specified by BIP350, although bitcoins spent to such addresses on mainnet will not be secure until activation of a soft fork using such addresses, such as taproot. The release additionally includes bug fixes and minor improvements.

Notable code and documentation changes

Bitcoin Core #21595 adds a new addrinfo command to the bitcoin-cli executable. Running bitcoin-cli -addrinfo returns a count of the network addresses of potential peers known to the node, split by network type. Sample output:

$ bitcoin-cli -addrinfo

{

“addresses_known”: {

“ipv4”: 14406,

“ipv6”: 2511,

“torv2”: 5563,

“torv3”: 2842,

“i2p”: 8,

“total”: 25330

}

Rust-Lightning #844 adds support for message signing, signature verification, and public key recovery using a scheme compatible with those of LND, C-Lightning, and Eclair.
BTCPay Server #2356 adds support for multifactor authentication using the WebAuthN/FIDO2 protocols. Existing multifactor authentication in BTCPay using U2F continues to work.
Libsecp256k1 #906 reduces the number of iterations needed to compute modular inverses from 724 to 590 when using a constant-time algorithm that should be more resistant to side-channel attacks than a variable-time algorithm. The correctness of the algorithm was checked using the Coq proof assistant, with the most strict verification taking approximately 66 days of runtime. See Newsletter #136 for more information about the algorithmic advance that led to this improvement.

Find the original post here.

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.