This week’s newsletter describes a proposal for using fidelity bonds on LN to prevent denial of service attacks, summarizes a PR to address a fee siphoning attack that could affect LN channels using anchor outputs, and links to a proposed specification for miniscript. Also included are our regular sections with releases, release candidates, and recent code changes in popular Bitcoin infrastructure software.

Action items

None this week.

News

• ● Fidelity bonds for LN routing: Gleb Naumenko and Antoine Riard posted a to the Lightning-Dev mailing list to use stake certificates (another name for fidelity bonds) to prevent a type of channel jamming attack first described in 2015. These are attacks where a malicious user sends a payment to themselves or a confederate through a series of channels and then delays either accepting or rejecting the payment. Until the payment eventually times out, each channel used to route the payment is unable to use those funds to route other user’s payments. Since a route may cross more than a dozen channels, that means every bitcoin controlled by the attacker can prevent more than a dozen bitcoins belonging to honest nodes from being used for honest routing.

  Previously proposed solutions for this problem (and related problems) mostly involved upfront fees, see Newsletters #72, #86, #119, #120, and #122. This week, Naumenko and Riard proposed that each payment include proof that its spender controlled some amount of bitcoin. Each routing node could then publicly announce its policy on how much value it would route given proof of a certain stake value. For example, Alice’s node could announce that it would route payments up to 0.01 BTC from anyone who could prove they controlled at least 1.00 BTC. This would allow someone to route a payment through Alice’s node but limit how much of her capital they could tie up.

  The mailing list post does note that a significant amount of work would need to be done to implement the idea, including the development of a privacy-preserving cryptographic proof. Discussion of the idea is still ongoing as of this writing.

• ● Proposed intermediate solution for LN SIGHASH_SINGLE fee theft: as described in Newsletter #115, a recent update to the LN specification that has not yet been widely deployed makes it possible for an attacker to steal a portion of the bitcoins allocated to paying onchain fees for LN payments (HTLCs). This is a consequence of spending HTLCs with signatures using the sighash flag SIGHASH_SINGLE|SIGHASH_ANYONECANPAY.

  The preferred solution to that problem is to simply not include any fees in HTLCs, eliminating the ability to steal fees and making the party who wants to claim the HTLC responsible for paying any necessary fees. However, this requires an additional change to the LN specification that would need to be adopted by all implementations of anchor outputs. In the meantime, Johan Halseth posted to the Lightning-Dev mailing list this week about a PR he opened to LND that will only accept a payment if the maximum amount of fees a peer can steal from that payment (and all previously accepted pending payments) is less than the channel reserve—the minimum amount that must be kept in each side of a channel to serve as a penalty in case an old state is broadcast. This doesn’t eliminate the problem, but it does significantly limit the maximum loss possible. A downside is that channels with only small amounts of value (and thus small reserves) will be limited to only forwarding a small number of HTLCs simultaneously. Halseth’s PR attempts to mitigate this by not requesting feerate increases above 10 sat/vbyte, keeping HTLC fees low so that the fees from several HTLCs are less likely to exceed reserves.

• ● Formal specification of miniscript: Dmitry Petukhov published a formal specification of miniscipt based on the documentation written by other developers. This could help with testing implementations or in extending miniscript in the future.

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.

• ● HWI 1.2.1 is a maintenance release that provides compatibility with a recent version of Ledger’s firmware and improves compatibility with the BitBox02.

• ● Rust-Lightning 0.0.12 is a release that updates several APIs to make them easier to use and adds “beta status” C/C++ bindings (see Newsletter #115).

• ● Bitcoin Core 0.21.0rc2 is a release candidate for the next major version of this full node implementation and its associated wallet and other software.

Notable code and documentation changes

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

• ● LND #4752 prevents the node from releasing a local payment preimage without a payment secret, contained in a field that is not available for passthrough payments. The patch requires adding payment secrets to the invoices that LND produces. Payment secrets were added as part of multipath payments and requiring them provides additional protection against improper preimage revelation for passthrough payments as described in Newsletter #121 and #122.