This week’s newsletter links to a draft BIP for the proposed OP_VAULT opcode, summarizes a discussion about allowing LN nodes to set a quality-of-service flag on their channels, relays a request for feedback on LN neighbor-node evaluation criteria, and describes a draft BIP for a seed backup and recovery scheme that can be reliably performed without electronics. Also included are our regular sections with summaries of popular questions and answers from the Bitcoin StackExchange, announcements of new releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.

News

  • ● Draft BIP for OP_VAULT: James O’Beirne posted to the Bitcoin-Dev mailing list a link to a draft BIP for the OP_VAULT opcode he previously proposed (see Newsletter #234). He also announced that he’ll be attempting to get the code merged into Bitcoin Inquisition, a project for testing major proposed changes to Bitcoin’s consensus and network protocol rules.

  • ● LN quality of service flag: Joost Jager posted to the Lightning-Dev mailing list a proposal to allow nodes to signal that a channel is “highly available”, indicating that its operator believes it’ll be able to forward payments without failure. If it does fail to forward a payment, the spender may choose not to use that node for future payments for a very long time—a much longer duration than the spender may use for nodes that did not advertise high availability. Spenders maximizing payment speed (rather than low fees) would preferentially choose payment paths consisting of self-identified highly available nodes.

    Christian Decker replied with an excellent summary of problems in reputation systems, including cases of self-proclaimed reputation. One of his concerns was that typical spenders won’t send anywhere near enough payments to frequently encounter the same nodes in a large network of payment channels. If repeat business is rare anyway, then the threat of temporarily not providing repeat business may not be effective.

    Antoine Riard reminded participants about an alternative approach to speeding up payments—overpayment with recovery. Previously described as boomerang payments (see Newsletter #86) and refundable overpayments (see Newsletter #192), a spender would take their payment amount plus some extra money, split it into several parts, and send the parts by a variety of routes. When a sufficient number of parts has arrived to pay the invoice, the receiver claims just those parts and rejects any additional parts (with additional funds) that arrive later. This requires spenders wanting fast payments to have some additional funds in their channel but it works even if some of the paths selected by the spender fail. This reduces the need for spenders to be able to easily find highly available channels. The challenge of this approach is building a mechanism that prevents receivers from keeping any overpayment that arrives.

  • ● Feedback requested on LN good neighbor scoring: Carla Kirk-Cohen and Clara Shikhelman posted to the Lightning-Dev mailing list to request feedback on the recommend parameters for how a node should judge whether its channel counterparties are a good source of forwarded payments. They suggest several criteria to judge by and recommended default parameters for each criterion, but are seeking feedback about the choices made.

    If a node determines that one of its peers is a good neighbor and that neighbor tags a forwarded payment as being endorsed by it, the node can give that payment access to more of its resources than it gives unqualified payments. The node may also endorse the payment when forwarding it to the next channel. As described in a prior paper co-authored by Shikhelman (see Newsletter #226), this is part of a proposal to mitigate channel jamming attacks.

  • ● Proposed BIP for Codex32 seed encoding scheme: Russell O’Connor and Andrew Poelstra (using anagrams of their names) proposed a BIP for a new scheme backing up and restoring BIP32 seeds. Similar to SLIP39, it optionally allows creating several shares using Shamir’s Secret Sharing Scheme (SSSS), requiring that a configurable number of the shares to be used together to recover the seed. An attacker who obtains less than the threshold number of shares will learn nothing about the seed. Unlike BIP39, Electrum, Aezeed, and SLIP39 recovery codes that use a wordlist, Codex32 instead uses the same alphabet as bech32 addresses. An example share from the draft BIP:

      ms12namea320zyxwvutsrqpnmlkjhgfedcaxrpp870hkkqrm

    The main advantage of Codex32 over all existing schemes is that all operations can be performed using just pen, paper, instructions, and paper cutouts. That includes generating an encoded seed (dice can be used here), protecting the seed with a checksum, generating checksummed shares, verifying checksums, and recovering the seed. We found the idea of being able to manually verify checksums on backups of seeds or shares to be an especially powerful concept. The only current method users have to verify an individual seed backup is to enter it into a trusted computing device and see if it derives the expected public keys—but determining whether a device should be trusted is often not a trivial procedure. Worse, in order to verify the integrity of existing SSSS shares (e.g. in SLIP39), the user must bring together each share they want to verify with enough other shares to reach the threshold and then enter them into a trusted computing device. That means verifying share integrity negates a large benefit of having shares in the first place—the ability to keep information safe and secure by distributing it across multiple places or people. With Codex32, users can verify the integrity of each share individually on a regular basis using just paper, pen, some printed materials, and a few minutes of time.

    Discussion on the mailing list mainly focused on the differences between Codex32 and SLIP39, which has been used in production for a couple of years now. We recommend anyone interested in Codex32 investigate its website or watch a video by one of its authors. With the draft BIP, the authors hope to see wallets begin to add support for using Codex32-encoded seeds.

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.

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.

  • ● BDK 0.27.1 is a security update to fix a vulnerability that “sometimes […] allows an array-bounds overflow when large string were input into SQLite’s printf function”. Only software using BDK’s optional SQLite’s database feature needs to be updated. See the vulnerability report for additional details.

  • ● Core Lightning 23.02rc3 is a release candidate for a new maintenance version of this popular LN implementation.

Notable code and documentation changes

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

  • ● Bitcoin Core #24149 adds signing support for P2WSH-based miniscript-based output descriptors. Bitcoin Core will be able to sign any miniscript descriptor input if all the necessary preimages and keys are available and timelocks are satisfied. Some features are still missing for full Miniscript support in the Bitcoin Core wallet: the wallet cannot yet estimate the input weight for some descriptors before signing and cannot yet sign PSBTs in some edge-cases. Miniscript support for P2TR outputs is also still pending.

  • ● Bitcoin Core #25344 updates the bumpfee and psbtbumpfee RPCs for creating Replace By Fee (RBF) fee bumps. The update allows specifying outputs for the replacement tranaction. The replacement may contain a different set of outputs than the transaction being replaced. This can be used to add new outputs (e.g. for iterative payment batching) or to remove outputs (e.g. for attempting to cancel an unconfirmed payment).

  • ● Eclair #2596 limits the number of times a peer attempting to open a dual funded channel can RBF fee bump the channel open transaction before the node won’t accept any further attempted updates. This is motivated by the node needing to store data about all possible versions of the channel open transaction, so allowing unlimited fee bumps could be a problem. Normally, the number of fee bumps that can be created is bounded in practice by the need for each replacement to pay additional transaction fees. However, the dual funding protocol expects a node to store even those fee bumps it can’t fully validate, meaning an attacker could create an unlimited number of invalid fee bump transactions that will never confirm and never cost it any transaction fees.

  • ● Eclair #2595 continues the project’s work on adding support for splicing, in this case with updates to the functions used for constructing transactions.

  • ● Eclair #2479 adds support for paying offers in the following flow: a user receives an offer, tells Eclair to pay it, Eclair uses the offer to fetch an invoice from the receiver, verifies the invoice contains the expected parameters, and pays the invoice.

  • ● LND #5988 adds a new optional probability estimator for finding payment paths. It is partly based on previous pathfinding research (see Newsletter #192) with additional input from other approaches.

  • ● Rust Bitcoin #1636 adds a predict_weight() function. Input to the function is a template for the transaction to construct; output is the expected weight of the transaction. This is especially useful for fee management: to determine which inputs need to be added to a transaction, the fee amount needs to be known, but to determine the fee amount, the size of the transaction needs to be known. The function can provide a reasonable size estimate without actually having to construct a candidate transaction.