Bitcoin Optech Newsletter #126 Bitcoin Optech

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.

—Source link—