This week’s newsletter summarizes a proposal for a modified version of LN that may improve compatibility with channel factories, describes software for mitigating some effects of channel jamming attacks without changing the LN protocol, and links to a website for tracking unsignaled transaction replacements. Also included are our regular sections with announcements of new client and service software, summaries of popular questions and answers on the Bitcoin Stack Exchange, and descriptions of notable changes to popular Bitcoin infrastructure software.

News

  • ● Factory-optimized LN protocol proposal: John Law posted to the Lightning-Dev mailing list the description of a protocol optimized for creating channel factories. Channel factories allow multiple users to trustlessly open multiple channels between pairs of users with only a single transaction onchain. For example, 20 users could cooperate to create an onchain transaction about 10 times larger than a normal two-party open but which opened a total of 190 channels.

    Law notes that the existing LN channel protocol (commonly called LN-penalty) creates two problems for channels opened from within a factory:

    • ● Long required HTLC expiries: trustlessness requires that any participant in a factory be able to exit it and regain exclusive control over their funds onchain. This is accomplished by the participant publishing the current state of balances in the factory onchain. However, a mechanism is needed to prevent the participant from publishing an earlier state, e.g. one where they controlled a greater amount of money. The original factory proposal accomplishes this by using one or more timelocked transactions that ensure more recent states can be confirmed more quickly than outdated states.

      A consequence of this, described by Law, is that any LN payment (HTLC) that is routed through a channel in a channel factory needs to provide enough time for the latest state timelock to expire so the factory can be unilaterally closed. Worse, this applies each time a payment is forwarded through a factory. For example, if a payment is forwarded through 10 factories each with a 1-day expiry, it’s possible that a payment could be jammed by accident or on purpose for 10 days (or longer, depending on other HTLC settings).

    • ● All or nothing: for factories to truly achieve their best efficiencies, all of their channels also need to be cooperatively closed in a single onchain transaction. Cooperative closes aren’t possible if any of the original participants becomes unresponsive—and the chance of a participant becoming unresponsive approaches 100% as the number of participants increases, limiting the maximum benefit factories can provide.

      Law cites previous work in allowing factories to remain operational even if one participant wants to leave or, conversely, one participant becomes unresponsive, such as the proposals for OP_TAPLEAF_UPDATE_VERIFY and OP_EVICT (see Newsletters #166 and #189).

    Three proposed protocols are presented by Law to address the concerns. All derive from a previous proposal by Law posted in October for tunable penalties—the ability to separate the management of the enforcement mechanism (penalties) from the management of other funds. That previous proposal has not yet received any discussion on the Lightning-Dev mailing list. As of this writing, Law’s new proposal has also not received any discussion. If the proposals are sound, they would have the advantage over other proposals of not requiring any changes to Bitcoin’s consensus rules.

  • ● Local jamming to prevent remote jamming: Joost Jager posted to the Lightning-Dev mailing list a link and explanation for his project, CircuitBreaker. This program, designed to be compatible with LND, enforces limits on the number of pending payments (HTLCs) the local node will forward on behalf of each of its peers. For example, consider the worst case HTLC jamming attack:

    Illustration of two different jamming attacks

    With the current LN protocol, Alice is fundamentally limited to concurrently forwarding a maximum of 483 pending HTLCs. If she instead uses CircuitBreaker to limit her channel with Mallory to 10 concurrent pending HTLC forwards, her downstream channel with Bob (not visualized) and all other channels in this circuit will be protected from all but those first 10 HTLCs that Mallory keeps pending. This may significantly reduce the effectiveness of Mallory’s attack by requiring she open many more channels to block the same number of HTLC slots, which may increase the cost of the attack by requiring she pay more onchain fees.

    Although CircuitBreaker was originally implemented to simply refuse to accept any HTLCs in any channel which exceeded its limit, Jager notes that he recently implemented an optional additional mode which puts any HTLCs in a queue rather than immediately refusing or forwarding them. When the number of concurrent pending HTLCs in a channel drops below the channel limit, CircuitBreaker forwards the oldest non-expired HTLC from the queue. Jager describes two advantages of this approach:

    • ● Backpressure: if a node in the middle of a circuit refuses an HTLC, all nodes in the circuit (not just those further down the circuit) can use that HTLC’s slot and funds to forward other payments. That means there’s limited incentive for Alice to refuse more than 10 HTLCs from Mallory—she can simply hope that some later node in the circuit will run CircuitBreaker or equivalent software.

      However, if a later node (say Bob) uses CircuitBreaker to queue excess HTLCs, then Alice could still have her HTLC slots or funds exhausted by Mallory even though Bob and later nodes in the circuit retain the same benefits as now (with the exception of possibly increased channel closing costs for Bob in some cases; see Jager’s email or the CircuitBreaker documentation for details). This gently pressures Alice into running CircuitBreaker or something similar.

    • ● Failure attribution: the current LN protocol allows (in many cases) a spender to identify which channel refused to forward an HTLC. Some spender software tries to avoid using those channels in future HTLCs for a certain amount of time. In the case of refusing HTLCs from malicious actors like Mallory, this obviously doesn’t matter, but if a node running CircuitBreaker refuses HTLCs from honest spenders, this may not only reduce its income from those refused HTLCs but also the income it would’ve received from subsequent payment attempts.

      However, the LN protocol doesn’t currently have a widely deployed way to determine which channel delayed an HTLC, so it’s less consequential in this regard to delay forwarding an HTLC than it is to outright refuse to forward it. Jager notes that this is changing due to many LN implementations working on supporting more detailed onion-routed error messages (see Newsletters #224), so this advantage may disappear some day.

    Jager calls CircuitBreaker, “a simple but imperfect way to deal with channel jamming and spamming”. Work continues on finding and deploying a protocol-level change that will more comprehensively mitigate concerns about jamming attacks, but CircuitBreaker stands out as a seemingly reasonable solution that’s compatible with the current LN protocol and which any LND user can deploy immediately on their forwarding node. CircuitBreaker is MIT licensed and conceptually simple, so it should be possible to adapt or port for other LN implementations.

  • ● Monitoring of full-RBF replacements: developer 0xB10C posted to the Bitcoin-Dev mailing list that they’ve begun providing publicly accessible monitoring of transaction replacements in the mempool of their Bitcoin Core node that don’t contain the BIP125 signal. Their node allows full-RBF replacement using the mempoolfullrbf configuration option (see Newsletter #208).

    Users and services can use the website as an indicator for which large mining pools might be currently confirming unsignaled replacement transactions (if any are doing so). However, we remind readers that payments received in unconfirmed transactions cannot be guaranteed even if miners don’t currently seem to be mining unsignaled replacements.

Changes to services and client software

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

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments 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.

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.1 is a major release of the mostly widely used full node software. Its new features include an option for configuring the node’s Replace-By-Fee (RBF) policy, a new sendall RPC for easily spending all of a wallet’s funds in a single transaction (or for otherwise creating transactions with no change output), a simulaterawtransaction RPC that can be used to verify how a transaction will effect a wallet (e.g., for ensuring a coinjoin transaction only decreases the value of a wallet by fees), the ability to create watch-only descriptors containing miniscript expressions for improved forward compatibility with other software, and the automatic application of certain setting changes made in the GUI to RPC-based actions. See the release notes for the full list of new features and bug fixes.

    Note: a version 24.0 was tagged and had its binaries released, but project maintainers never announced it and instead worked with other contributors to resolve some last-minute issues, making this release of 24.0.1 the first announced release of the 24.x branch.

  • ● libsecp256k1 0.2.0 is the first tagged release of this widely-used library for Bitcoin-related cryptographic operations. An announcement of the release states, “for a long time, libsecp256k1’s development only had a master branch, creating unclarity about API compatibility and stability. Going forward, we will be creating tagged releases when relevant improvements are merged, following a semantic versioning scheme. […] We’re skipping version 0.1.0 because this version number was set in our autotools build scripts for years, and does not uniquely identify a set of source files. We will not be creating binary releases, but will take expected ABI compatibility issues into account for release notes and versioning.”

  • ● Core Lightning 22.11.1 is a minor release that temporarily reintroduces some features that were deprecated in 22.11, as requested by some downstream developers.

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.

  • ● Bitcoin Core #25934 adds an optional label argument to the listsinceblock RPC. Only transactions matching the label will be returned when a label is specified.

  • ● LND #7159 updates the ListInvoiceRequest and ListPaymentsRequest RPCs with new creation_date_start and creation_date_end fields that can be used to filter out invoices and payments before or after the indicated date and time.

  • ● LDK #1835 adds a fake Short Channel IDentifier (SCID) namespace for intercepted HTLCs, enabling Lightning Service Providers (LSPs) to create a just-in-time (JIT) channel for end users to receive a lightning payment. This is done by including fake route hints in end-user invoices that signal to LDK that this is an intercept forward, similar to phantom payments (see Newsletter #188). LDK then generates an event, allowing the LSP the opportunity to open the JIT channel. The LSP can then forward the payment over the newly opened channel or fail it.

  • ● BOLTs #1021 allows onion-routing error messages to contain a TLV stream, which may be used in the future to include additional information about the failure. This is a first step towards implementing fat errors as proposed in BOLTs #1044.

Happy holidays!

This is Bitcoin Optech’s final regular newsletter of the year. On Wednesday, December 21st, we’ll publish our fifth annual year-in-review newsletter. Regular publication will resume on Wednesday, January 4th.