Bitcoin Optech Newsletter #145 – Bitcoin Magazine: Bitcoin News, Articles, Charts, and Guides

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 describes progress on activating taproot, summarizes an update to LN offers to partly address stuck payments, relays a request for feedback on anchor outputs in LND, and announces the public launch of the Sapio smart contract development toolkit. Also included are our regular sections with summaries of changes to popular clients and services, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

News

Taproot activation release candidate: since our update on taproot activation in last week’s newsletter, the Bitcoin Core Project has merged a pull request implementing the Speedy Trial activation mechanism and a second PR containing the activation parameters. These PRs and a few others are currently part of the first Release Candidate (RC) for Bitcoin Core 0.21.1. Testing and other quality assurance tasks are expected to continue for at least several days after the publication of this newsletter. See the RC and merge summary sections below for more details.

Using LN offers to partly address stuck payments: in some cases, an attempt to pay an LN invoice can result in the payment becoming stuck for an extended period of time. Until the failure is resolved, requesting a second invoice to make a second payment attempt can result in paying twice.
This week, Rusty Russell posted to the Lightning-Dev mailing list a change to his proposed offers specification that allows the receiver of a payment to commit to a new invoice which supplants the previous invoice. If the spender pays the second invoice, there’s still a risk that they will pay twice, but the receiver’s signature on the offer combined with LN’s inherent proof of payment will allow the spender to prove the receiver acted deceitfully if both payments were accepted. When paying a receiver with an established reputation, such as a popular business, that may be enough to eliminate stuck payments as a major problem.
The update to the offers specification also allows the receiver to indicate that they received the payment and the problem is with a downstream node. In that case, the funds for both the spender and the receiver are fully secure and the only consequence is that the spender will need to wait a while before they can reuse that particular one of their payment slots (HTLC slots). This ability to communicate interactively is a clear advantage of offers over plain invoices.

Using anchor outputs by default in LND: Olaoluwa Osuntokun posted to the LND engineering mailing list about his desire for the next major version of LND to use anchor outputs by default. Anchor outputs will allow unconfirmed LN commitment transactions that close a channel to be CPFP fee bumped. Unfortunately, there are some challenges with CPFP fee bumping in the LN model:

Not always optional: for regular onchain transactions, many users can just wait longer for their transaction to confirm as an alternative to fee bumping. For LN, sometimes waiting isn’t an option—a fee bump will need to be submitted within a matter of hours or funds could be lost.
Timelocked outputs: for most regular onchain payments, a user who wants to CPFP bump can pay for a fee bump using the funds stored in their output from the transaction they want to bump. In the case of LN, those funds aren’t available until the channel close has been fully settled onchain. That means the user needs to use a separate UTXO to pay the fees.

To address the above two concerns, LND is requiring users of anchor outputs to retain at least one confirmed UTXO of reasonable value in their wallet any time a channel is open. That ensures they can CPFP fee bump when necessary, but it has certain consequences, such as preventing spending the last of your onchain funds (even to open a new channel) while you still have at least one channel open.
Osuntokun’s request is for wallets or services built on LND to let the development team know if any of the above concerns, or any other concerns related to anchor outputs, will cause serious problems. Although the question is specific to LND, the answers may have implications for all LN nodes.

Sapio public launch: Jeremy Rubin posted to the Bitcoin-Dev mailing list an announcement that he has made available the Sapio smart contract development toolkit, a Rust-based library and associated tooling that can be used to create smart contracts expressible using Bitcoin Script. The language was originally designed to make use of Rubin’s proposed OP_CHECKTEMPLATEVERIFY opcode (OP_CTV), but it can simulate the existence of that opcode, and of other potential features for Bitcoin such as taproot, using a trusted signing oracle. In addition to the Sapio library, the release also contains extensive documentation and an experimental frontend.

Changes to services and client software

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

Specter v1.3.0 released: Specter v1.3.0 includes additional RBF support, Bitcoin Core setup from within the application, HWI 2 support, and an option to use mempool.space as a block explorer and for fee estimation.
Specter-DIY v1.5.0: Hardware wallet firmware Specter-DIY released v1.5.0 which adds custom SIGHASH flag support and full descriptor support including miniscript.
BlueWallet v6.0.7 adds message signing: BlueWallet v6.0.7 allows users to sign and verify messages using Bitcoin addresses, among other features and fixes.
Azteco announces Lightning support: Bitcoin voucher company Azteco announced support for redeeming purchased bitcoins via Lightning Network.

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, if activated, will enforce the rules of the proposed taproot soft fork, which uses schnorr signatures and allows 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

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.

Source