This week’s newsletter links to a prototype for creating vaults using pre-signed transactions and includes our regular sections about notable changes to services, client software, and popular Bitcoin infrastructure projects.

Action items

None this week.

News

  • ● Vaults prototype: Bryan Bishop has announced a Python-language prototype of the vaults covenant described in Newsletter #59. The mechanism uses ephemeral keys and pre-signed time-locked transactions to allow you to detect that someone used one of your private keys in an attempted theft. You (or a watchtower acting on your behalf) can then activate an emergency protocol to recover most of the secured funds. The prototype also includes an implementation of the same basic mechanism using BIP119’s proposed opcode OP_CHECKTEMPLATEVERIFY.

Changes to services and client software

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

  • ● BTCPay adds support for sending and receiving payjoined payments: payjoin is a protocol that increases the privacy of Bitcoin payments by including inputs from both the spender and the receiver in an onchain transaction. This prevents an outside observer examining block chain data from assuming all inputs in that transaction belong to the same user (e.g.1). If a significant number of people use payjoin, this makes the common input heuristic used by block chain analysts much less reliable, improving privacy for even Bitcoin users who aren’t using payjoin.

    This week, BTCPay announced the release of version 1.0.4.0 which includes an implementation of payjoin support for both receiving payments in payment processor mode and sending them using BTCPay’s internal wallet. For details on using the protocol, see their user guide. For technical details on their implementation, see their specification or the issue where future improvements are being actively discussed. For this change to have the maximum impact, other popular wallets need to implement support for creating compatible payjoin payments.

  • ● Lightning Labs drafts Lightning Service Authentication Tokens (LSAT) specification: Lightning Labs has announced LSAT, a specification, which outlines a protocol for purchasing tokens (macaroons) over LN and using them in an application as both authentication and API payment mechanisms.

  • ● Lightning Labs announces Faraday for channel management: Faraday is a tool for LND node operators that analyzes existing channels and makes recommendations to close problematic or under-performing channels. Such channels display attributes such as low volume, low uptime, or high fees.

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.

Notable code and documentation changes

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

  • ● Bitcoin Core #17595 adds support for reproducibly building the Windows versions of Bitcoin Core using GNU Guix. The last remaining target platform for Guix reproducible builds, macOS, has an open draft PR.

  • ● C-Lightning #3611 adds a keysend plugin that allows a node to securely receive spontaneous payments—payments not preceded by the generation of an invoice. These work by having the sender of a payment choose its payment preimage (normally chosen by the receiver), derive its payment hash (normally included in an invoice), encrypt the preimage to the receiver’s node pubkey, and send a payment with the encrypted data to the receiver secured by the payment hash. The receiver decrypts the preimage and uses it to claim the payment like normal. In order to allow payment tracking, lightningd automatically creates an internal invoice for the decrypted preimage before claiming a spontaneous payment. An obvious use for spontaneous payments is donations, but a less obvious use is for sending chat messages with a payment such as via the LND-compatible WhatSat software and the C-Lightning-compatible noise plugin.

  • ● C-Lightning #3623 adds a minimal implementation (only available with the configuration parameter --enable-experimental-features) for spending payments using blinded paths. As described in Newsletter #92, blinded paths make it possible to route a payment without the originator learning the destination’s network identity or the full path used. This not only improves the privacy of the origination and destination endpoints but also the privacy of any unannounced nodes along the blinded paths. The minimal implementation in this PR is mainly designed for testing, such as with a work-in-progress implementation being developed for Eclair.

  • ● LND #4163 adds a version RPC that returns information about the LND server version and build flags. This makes it easier for applications to ensure they’re compatible with the currently running LND version.

  • ● Rust-Lightning #441 adds support for sending and receiving basic multipath payments. This implementation is not fully usable yet as follow-up pull requests are needed to add support for route finding and for timing out partial payments.

Footnotes

  1. An example of what the users participating in a payjoin know about a transaction versus what block chain analysts can infer.

      What Alice and Bob know What the network sees
    Current norm Inputs:
      Alice (1 BTC)
      Alice (4 BTC)

    Outputs:
      Alice’s change (2 BTC)
      Bob’s revenue (3 BTC)    		 Inputs:
      Spender (1 BTC)
      Spender (4 BTC)

    Outputs:
      Spender or Receiver (2 BTC)
      Spender or Receiver (3 BTC)
    With payjoin Inputs:
      Alice (1 BTC)
      Alice (4 BTC)
      Bob (3 BTC)

    Outputs:
      Alice’s change (2 BTC)
      Bob’s revenue & change (6 BTC)    		 Inputs:
      Spender or Receiver (1 BTC)
      Spender or Receiver (4 BTC)
      Spender or Receiver (3 BTC)

    Outputs:
      Spender or Receiver (2 BTC)
      Spender or Receiver (6 BTC)

    ↩