This week’s newsletter describes a proposal for new opt-in transaction relay rules and summarizes research into helping LN channels stay balanced. Also included are our regular sections listing new software releases and release candidates plus notable changes to popular Bitcoin infrastructure projects.

News

  • ● Proposed new transaction relay policies designed for LN-penalty: Gloria Zhao posted to the Bitcoin-Dev mailing list a proposal to allow transactions to opt-in to a modified set of transaction relay policies. Any transaction which sets its version parameter to 3 will:

    • Be replaceable while it is unconfirmed by a transaction paying a higher feerate and a higher total fee (the current main RBF rules)

    • Require all of its descendents also be v3 transactions for as long as it remains unconfirmed. Descendents violating this rule will not be relayed or mined by default

    • Be rejected if any of its v3 unconfirmed ancestors already have any other descendants in the mempool (or in a package containing this transaction)

    • Be required to be 1,000 vbytes or smaller if any of its v3 ancestors are unconfirmed

    Accompanying the proposed relay rules was a simplification of the previously-proposed package relay rules (see Newsletter #167).

    Together, the v3 relay and updated package relay rules are designed to allow LN commitment transactions to include only minimal fees (or potentially even zero fees) and have their actual fees paid by a child transaction, all while preventing pinning. Almost all LN nodes already use a mechanism like this, anchor outputs, but the proposed upgrade should make confirming commitment transactions simpler and more robust.

    Greg Sanders replied with two suggestions:

    • ● Ephemeral dust: any transactions paying a zero-value (or otherwise uneconomical) output should be exempt from the dust policy if that transaction is part of a package which spends the dust output.

    • ● Standard OP_TRUE: that outputs paying an output consisting entirely of OP_TRUE should be relayed by default. Such an output can be spent by anyone—it has no security. That makes it easy for either party to an LN channel (or even third parties) to fee-bump a transaction spending that OP_TRUE output. No data needs to be put on the stack to spend an OP_TRUE output, making it cost-efficient to spend.

    Neither of these needs to be done at the same time as implementing relay of v3 transactions, but several respondents to the thread seemed to be in favor of all the proposed changes.

  • ● LN flow control: Rene Pickhardt posted to the Lightning-Dev mailing list a summary of recent research he performed on using the htlc_maximum_msat parameter as a flow control valve. As previously defined in BOLT7, htlc_maximum_msat is the maximum value that a node will forward to the next hop in a particular channel for an individual payment part (HTLC). Pickhardt addresses the problem of a channel with more value flowing through it in one direction than the other direction—eventually leaving the channel without enough funds to transfer in the overused direction. He suggests that channel can be kept in balance by limiting the maximum value in the overused direction. For example, if a channel starts by allowing 1,000 sat forwards in either direction but becomes unbalanced, then try lowering the overused direction’s maximum amount per forwarded payment to 800. Pickhardt’s research provides several code snippets that can be used to calculate actual appropriate htlc_maximum_msat values.

    In a separate email, Pickhardt also suggests that the previous idea of fee ratecards (see last week’s newsletter) could instead become maximum amount per-forward ratecards, where a spender would be charged a lower feerate to send small payments and a higher feerate to send larger payments. Unlike the original ratecards proposal, they would be absolute amounts and not relative to the channel’s current balance. Anthony Towns described several challenges with the original ratecards idea that wouldn’t be problems for flow control based on adjusting htlc_maximum_msat.

    ZmnSCPxj criticized several aspects of the idea, including noting that spenders could still send the same amount of value through a lower-max rate channel, resulting in it again becoming unbalanced, just by splitting an overall payment into additional small parts. Towns suggested this could potentially be addressed by rate limiting.

    The discussion appeared to be ongoing at the time this summary was being written, but we expect that several new insights will come in the following weeks and months as node operators begin experimenting with their channels htlc_maximum_msat parameters.

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, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● Eclair #2435 adds optional support for a basic form of async payments when trampoline relay is used. As described in Newsletter #171, async payments would allow paying an offline node (such as a mobile wallet) without trusting a third-party with the funds. The ideal mechanism for async payments depends on PTLCs, but a partial implementation just requires a third party to delay forwarding the funds until the offline node comes back online. Trampoline nodes can provide that delay and so this PR makes use of them to allow experimentation with async payments.

  • ● BOLTs #962 removes support for the original fixed-length onion data format from the specification. The upgraded variable-length format was added to the specification over three years ago and test results mentioned in the commit message indicate almost no one is using the older format any more.

  • ● BIPs #1370 revises BIP330 (Erlay for reconciliation-based transaction announcements) to reflect the current proposed implementation. Changes include:

    • Removing truncated transaction IDs in favor of just using transaction wtxids. This also means nodes can use the existing inv and getdata messages, so the invtx and gettx messages have been removed.

    • Renaming sendrecon to sendtxrcncl, reqreconcil to reqrecon, and reqbisec to reqsketchtext.

    • Adding details for negotiating support using sendtxrcncl.

  • ● BIPs #1367 simplifies BIP118’s description of SIGHASH_ANYPREVOUT by referring to BIPs 340 and 341 as much as possible.

  • ● BIPs #1349 adds BIP351 titled “Private Payments”, describing a cryptographic protocol inspired by BIP47 and Silent Payments. The BIP introduces a new Payment Code format per which participants specify supported output types next to their public key. Similar to BIP47, a sender uses a notification transaction to establish a shared secret with the receiver based on the receiver’s Payment Code. The sender can then send multiple payments to unique addresses derived from the shared secret which the receiver may spend using information from the notification transaction. Where BIP47 had multiple senders reuse the same notification address per receiver, this proposal uses OP_RETURN outputs labeled with the search key PP and a notification code specific to the sender-receiver pair to get the receiver’s attention and establish the shared secret for improved privacy.

  • ● BIPs #1293 adds BIP372 titled “Pay-to-contract tweak fields for PSBT”. This BIP proposes a standard for including additional PSBT fields that provide signing devices with contract commitment data required to participate in Pay-to-Contract protocols (see Newsletter #184).

  • ● BIPs #1364 adds additional detail to the text for the BIP300 specification of drivechains. The related specification of BIP301 for enforcing drivechain’s blind merge mining rules is also updated.