This week’s newsletter describes a proposal to enable generalized smart contracts on Bitcoin and summarizes a paper about addressing LN channel jamming attacks. Also included are our regular sections with descriptions of changes to services and client software, announcements of new releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.

News

  • ● General smart contracts in Bitcoin via covenants: Salvatore Ingala posted to the Bitcoin-Dev mailing list a proposal for a new type of covenant (requiring a soft fork) that would allow using merkle trees to create smart contracts that can carry state from one onchain transaction to another. To use an example from Ingala’s post, two users could wager on a game of chess where the contract could hold the rules of the game and the state could hold the positions of all the pieces on the board, with it being possible to update that state by each onchain transaction. Of course, a well-designed contract would allow the game to be played offchain with only the settlement transaction at the end of the game being put onchain (or possibly even then staying offchain if the game was played within another offchain construct, such as a payment channel).

    Ingala explains how the work could help design joinpools, optimistic rollups (see Newsletter #222), and other stateful constructions.

  • ● Paper about channel jamming attacks: Clara Shikhelman and Sergei Tikhomirov posted to the Lightning-Dev mailing list the summary of a paper they’ve written about solutions to channel jamming attacks. These attacks, first described in 2015, can make large numbers of channels unusable for long periods of time at negligible cost to an attacker.

    The authors split jamming attacks into two types. The first is slow jamming where a channel’s limited slots or funds for payment forwarding are made unavailable for long periods of time—which rarely happens with legitimate payments. The second type is fast jamming where the slots and funds are blocked only briefly—which happens often with normal payments, potentially making fast jamming harder to mitigate.

    They suggest two solutions:

    • ● Unconditional fees (the same as upfront fees described in previous newsletters), where some amount of fee is paid to forwarding nodes even if a payment fails to reach the receiver. The authors suggest both a base upfront fee that’s independent of the amount of the payment and a proportional fee that increases with the payment amount. The two separate fees respectively address HTLC slot jamming and liquidity jamming. The fees can be very small because they’re only meant to prevent fast jamming, which requires frequent resends of fake payments that would each need to pay additional upfront fees, raising the cost for the attacker.

    • ● Local reputation with forwarding, where each node would keep statistics about each of its peers related to how long its forwarded payments remain pending and the forwarding fees collected. If a peer’s time per fee is high, it considers that peer high-risk and only allows that peer to use a limited number of the local node’s slots and funds. Otherwise, it considers the peer low-risk.

      When a node receives a forwarded payment from a peer it considers low-risk, it checks to see whether that peer tagged the payment as also being low-risk. If both the upstream forwarding node and the payment are low-risk, it allows the payment to use any available slot and funds.

    The paper received some discussion on the mailing list, with the proposed local reputation method specifically being praised.

Changes to services and client software

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

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.

  • ● Bitcoin Core 24.0 RC4 is a release candidate for the next version of the network’s most widely used full node implementation. A guide to testing is available.

    Warning: this release candidate includes the mempoolfullrbf configuration option which several protocol and application developers believe could lead to problems for merchant services as described in previous newsletters #222 and #223. It could also cause problems for transaction relay as described in Newsletter #224.

  • ● LND 0.15.5-beta.rc1 is a release candidate for a maintenance release of LND. It’s contains only minor bug fixes according to its planned release notes.

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.

  • ● Core Lightning #5681 adds the ability to filter the JSON output of an RPC on the server side. Filtering on the server side avoids sending unwanted data when using a bandwidth-constrained remote connection. In the future, some RPCs may be able to avoid computing filtered data, allowing them to return sooner. Filtering is not guaranteed for all RPCs, especially those provided by plugins. When filtering is not available, the unfiltered full output will be returned. For more information, see the added documentation.

  • ● Core Lightning #5698 updates the experimental developer mode to allow receiving onion-wrapped error messages of any size. BOLT2 currently recommends 256-byte errors, but it doesn’t forbid longer error messages and BOLTs #1021 is open to encourage use of 1024-byte error messages encoded using LN’s modern Type-Length-Value (TLV) semantics.

  • ● Core Lightning #5647 adds the reckless plugin manager. The plugin manager may be used to install CLN plugins by name from the lightningd/plugins repository. The plugin manager automatically installs dependencies and verifies the installation. It can also be used to enable and disable plugins as well as persist the plugin state in a configuration file.

  • ● LDK #1796 updates Confirm::get_relevant_txids() to return not just txids but also the hashes of the blocks containing those referenced transactions. This makes it easier for a higher-level application to determine when a block chain reorganization may have changed the confirmation depth of a transaction. If the block hash for a given txid changes, then a reorganization has occurred.

  • ● BOLTs #1031 allows a spender to pay a receiver slightly more than the requested amount when using simplified multipath payments. This may 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.