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.
- 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…