This week’s newsletter summarizes a discussion about allowing quantum-safe key exchange on Bitcoin and includes our regular sections with descriptions of notable changes to services and client software, releases and release candidates, and popular Bitcoin infrastructure software.

News

• ● Quantum-safe key exchange: Erik Aronesty started a thread on the Bitcoin-Dev mailing list about quantum resistance—keeping Bitcoin secure in case a fast Quantum Computer (QC) is developed. Fast QCs are predicted to be able to generate signatures corresponding to Bitcoin public keys without knowledge of the original private key, allowing someone possessing a fast QC to spend money belonging to other people. Few security researchers believe fast QCs are a near-term threat, but any method that can eliminate them as a concern without significantly disturbing existing uses of Bitcoin may warrant consideration.

  Aronesty suggested allowing users to receive payments to a public key secured by a quantum-safe algorithm—also perhaps securing the bitcoins with an existing-style Bitcoin public key so that an exploitable problem would need to be found with both key algorithms before any bitcoins could be stolen as the result of a cryptographic key failure. This would require a soft fork consensus change and would likely reduce the maximum number of useful transactions per block in the worst case given that quantum-safe witness data is larger than Bitcoin’s currently-used ECDSA and schnorr witness data.

  Lloyd Fournier suggested instead that a standardized scheme be developed that allows taproot outputs to commit to quantum-safe public keys in addition to their usual schnorr public keys. The quantum safe public keys might not be currently spendable, but if Bitcoin users became more concerned about an impending fast QC, they could choose to soft fork in a consensus change that required the quantum-safe spending paths be used. Fournier also suggested that details about the problem and possible solutions could be described for current and future researchers and developers on BitcoinProblems.org.

Changes to services and client software

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

• ● Bitcoin.com adds segwit sends: In a recent update to the Bitcoin.com wallet, sending to native segwit (bech32) addresses is now supported.

• ● Kraken adds Lightning support: Kraken, using LND, added support for Lightning deposits and withdrawals of up to 0.1 BTC.

• ● Cash App adds Lightning receive support: After previously adding LN send features, Cash App launched the ability for users to now receive payments via the Lightning Network. Cash App uses Lightning Development Kit (LDK) for LN features.

• ● BitPay adds Lightning receive support: Payment processor BitPay announced support for their merchants to accept LN payments.

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.

• ● LND 0.14.3-beta is a release with several bug fixes for this popular LN node software.

• ● Bitcoin Core 23.0 RC5 is a release candidate for the next major version of this predominant full node software. The draft release notes list multiple improvements that advanced users and system administrators are encouraged to test before the final release.

• ● Core Lightning 0.11.0rc3 is a release candidate for the next major version of this popular LN node software.

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.

• ● LND #5810 implements sending support for payment metadata. If an invoice includes payment metadata, a sender will encode that data as a TLV record for the receiver. This is another step towards unlocking stateless invoices which allow a receiver to forgo storing invoices shown to potential senders by regenerating them when a payment attempt reaches the receiver.

• ● LND #6212 prevents HTLCs from being sent through the HTLC interceptor to an external process if accepting the HTLC might require the channel be closed onchain immediately or within a short time. This can happen if the HTLC’s expiry is near the most recently seen block.

• ● LND #6024 adds a time_pref pathfinding parameter that can be used to change the tradeoff between routing through channels considered to be more likely to relay the payment (faster) and those which charge less fees.

• ● LND #6385 removes the option to use the original LN protocol onion payment format when constructing new payments, requiring the user now create a TLV-style onion format. TLV onions were added to the protocol in 2019 (see Newsletter #55) and have been the default in all LN software for over two years. Other LN software have been making similar changes to drop older onion format support, such as the update to Core Lightning reported in Newsletter #158.