Bitcoin Optech Newsletter #146 – 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 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.