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.
None this week.
● 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
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
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
Notable code and documentation changes
- ● 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