This week’s newsletter announces the latest C-Lightning release, requests help testing a Bitcoin Core release candidate, describes discussions about simplified LN commitments using CPFP carve-out, and summarizes several top-voted questions and answers from the Bitcoin StackExchange.

Action items

• ● Upgrade to C-Lightning 0.7.3: this latest release adds support for a PostgreSQL backend, makes it possible to send funds directly to a particular address when closing a channel, and allows you keep your HD wallet seed encrypted when lightningd isn’t running—plus many other features and several bug fixes.

• ● Help test Bitcoin Core release candidate: experienced users are encouraged to help test the latest release candidates for the upcoming version of Bitcoin Core.

News

• ● LN simplified commitments: in two separate threads, developers of LND discussed their work on implementing simplified commitments, which are LN settlement transactions that only pay a minimal onchain transaction fee and which contain two additional outputs (one for each party). The idea is to allow either party to choose what transaction fee they want to pay at the time the transaction is broadcast, which they can do using Child-Pays-For-Parent (CPFP) fee bumping from their individual output. Although this has been discussed in the past, it was vulnerable to an attack that is expected to be resolved by the inclusion of CPFP carve-out in the upcoming Bitcoin Core version 0.19.0 (see Newsletter #56).

  In the first thread, Johan Halseth posted an email about loosening mempool policy in order to make simplified commitments even simpler. This received several objections on the basis that a slight change wouldn’t be effective and too much change would put the network at risk of bandwidth-wasting attacks. However, this discussion (and a separate discussion started on the #bitcoin-core-dev IRC channel by Jeremy Rubin) revealed that many developers wanted to gain a better understanding of the current rules and how they might be improved. A good outline of the subject was sourced from a presentation given by Suhas Daftuar that has now been converted into a wiki page.

  In the second thread, Joost Jager resumed an old thread started by Rusty Russell with a proposed specification for simplified commitments (see Newsletter #23). Based on the upcoming carve-out feature and other developments in LN, Jager makes several suggestions, including: using the name “anchor output” for the outputs meant to be spent with CPFP; using an additional set of pubkeys for the anchors to ease splitting responsibilities between cold and hot wallets; and using static keys to simplify backup recovery. He subsequently opened a PR to the BOLTs repository to add simplified commitments to the LN protocol specification.

• ● Publication of videos and study material from schnorr/taproot workshop: Optech published a blog post with links to videos, Jupyter notebooks, GitHub repositories, and more information produced for the schnorr and taproot workshops held in San Francisco and New York City last month. These explain the fundamentals of both proposals, guide students through actually using them, and then describe strategies for making optimal use of the features they add to Bitcoin.

  All developers interested in these features which may be added to Bitcoin in the future are encouraged to review the study material, especially developers participating in the taproot review described in last week’s newsletter.

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 of time 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 does hashing public keys not actually provide any quantum resistance? Andrew Chow lists several considerations regarding public keys and quantum resistance, including: the need to reveal the public key during spending, the large number of bitcoins in outputs with known public keys, and numerous ways which public keys are exposed outside of just transacting due to not currently being treated as secrets.

• ● Will schnorr multi-signatures completely replace ECDSA? Ugam Kamat explains how the proposed addition of schnorr signatures in segwit v1 does not remove the need for ECDSA. ECDSA is required to spend non-segwit as well as segwit v0 outputs.

• ● Why doesn’t RBF include restrictions on the outputs? Andrew Chow gets into some of the design choices in BIP125 Opt-in Replace by Fee (RBF) and compares it to the First Seen Safe Replace by Fee (FSS-RBF) approach. Chow notes the drawbacks of FSS-RBF but also warns against the acceptance of any unconfirmed transaction.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, libsecp256k1, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

• ● Bitcoin Core #17165 removes support for the BIP70 payment protocol. This change has only been made on the master development branch and will probably not be released until version 0.20, expected about six months from now. BIP70 was made optional in version 0.18.0 and will be disabled by default in the upcoming 0.19.0; see Newsletter #19 for more information.

  This is the last significant feature in Bitcoin Core to depend on OpenSSL, and a PR has been opened to complete the removal of that dependency. OpenSSL has been the source of previous vulnerabilities in Bitcoin Core (e.g. Heartbleed and non-strict signature encoding) and much effort over the past five-plus years has been invested into eliminating it as a dependency.