This week’s newsletter summarizes an idea for watchtower accountability proofs and includes our regular sections with announcements of new releases and release candidates and descriptions of notable changes to popular Bitcoin infrastructure software.

News

• ● Watchtower accountability proofs: Sergi Delgado Segura posted to the Lightning-Dev mailing list last week about holding watchtowers accountable for failing to respond to protocol breaches they were capable of detecting. For example, Alice provides a watchtower with data for detecting and responding to the confirmation of an old LN channel state; later, that state is confirmed but the watchtower fails to respond. Alice would like to be able to hold the watchtower operator accountable by publicly proving it failed to respond appropriately.

  The basic principle would be for a watchtower to have a well-known public key and to use the corresponding private key to generate a signature for any breach-detection data it accepted. Alice could then publish the data and the signature after an unresolved breach to prove the watchtower failed its responsibility. However, Delgado noted that practical accountability isn’t that simple:

  • ● Data storage requirements: the above mechanism would require Alice to store an additional signature every time she sent the watchtower new breach-detection data, which could be quite often for an active LN channel.

  • ● No deletion capability: the above mechanism potentially requires the watchtower to store the breach-detection data in perpetuity. Watchtowers may only want to store data for a limited time, e.g. they may accept payment for a particular term.

  Delgado suggests cryptographic accumulators provide a practical solution to both problems. Accumulators allow compactly proving a particular element is a member of a large set of elements and also allow adding new elements to the set without rebuilding the entire data structure. Some accumulators allow deleting elements from the set without rebuilding. In a gist, Delgado outlines several different accumulator constructions worth considering.

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 v0.16.0-beta is beta release of a new major version of this popular LN implementation. Its release notes mention numerous new features, bug fixes, and performance improvements.

• ● BDK 1.0.0-alpha.0 is a test release of the major changes to BDK described in Newsletter #243. Developers of downstream projects are encouraged to begin integration testing.

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), Lightning BOLTs, and Bitcoin Inquisition.

• ● Core Lightning #5967 adds a listclosedchannels RPC that provides data about the node’s closed channels, including the cause of channel being closed. Information about old peers is also retained now.

• ● Eclair #2566 adds support for accepting offers. Offers must be registered by a plugin that provides a handler for responding to invoice requests related to the offer and either accepting or rejecting payments to that invoice. Eclair ensures requests and payments satisfy the protocol requirements—the handler only needs to decide whether the item or service being purchased can be provided. This allows code for marshaling offers to become arbitrarily complex without affecting Eclair’s internal logic.

• ● LDK #2062 implements BOLTs #1031 (see Newsletter #226), #1032 (see Newsletter #225), and #1040, allowing the ultimate receiver of a payment (HTLC) to accept a greater amount than they requested and with a longer time before it expires than they requested. This makes it more difficult for a forwarding node to use a slight tweak in the payment’s parameters to determine that the next hop is the receiver. The merged PR also allows a spender to pay a receiver slightly more than the requested amount when using simplified multipath payments. This provides the above benefit and may also be required in the case where the chosen payment paths use channels with a minimum routable amount. For example, Alice wants to split a 900 sat total into two parts, but both of the paths she chooses require 500 sat minimum amounts. With this specification change, she can now send two 500 sat payments, choosing to overpay by a total of 100 sats in order to use her preferred route.

• ● LDK #2125 adds helper functions to determine the amount of time until an invoice expires.

• ● BTCPay Server #4826 allows service hooks to create and retrieve LNURL invoices. This was done to add support for NIP-57 zaps to BTCPay Server’s lightning address features.

• ● BTCPay Server #4782 adds proof of payment on the receipt page for each payment. For onchain payments, the proof is the transaction ID. For LN payments, the proof is the preimage to the HTLC.

• ● BTCPay Server #4799 adds the ability to export wallet labels for transactions in the format specified by BIP329. Future PRs may add support for exporting other wallet data, such as labels for addresses.

• ● BOLTs #765 adds route blinding to the LN specification. Route blinding, which we first described in Newsletter #85, allows a node to receive a payment or onion message without revealing its node identifier to the spender or sender. No other directly identifiable information needs to be revealed. Route blinding works by having the receiver choose the last several hops over which the payment or message will be forwarded. These steps are onion encrypted like regular forwarding information and are provided to the spender or sender who uses them to send a payment to the first of the hops. That hop begins the process of decrypting the next hop, forwarding the payment to it, having that hop decrypt the subsequent hop, etc, until the receiver accepts the payment without their node being disclosed to the spender or sender.