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.


  • Fidelity bonds for LN routing: Gleb Naumenko and Antoine Riard
    posted a to the Lightning-Dev mailing list to use stake
    (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

    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
, 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

—Source link—

What do you think?

How to trade BTC and ETH options Bankless

F1® Delta Time track NFT sells for over $223,000 DappRadar Blog RSS Feed