Bitcoin Optech Newsletter #103

This week’s newsletter summarizes a newly published fee ransom attack against
LN users, links to continued discussion about the attack against LN
atomicity, and shares a reminder about collision attacks on
RIPEMD160-based addresses in multiparty protocols. Also included are
our regular sections with popular questions and answers from the Bitcoin
StackExchange, a list of releases and release candidates published this
week, and notable changes to popular Bitcoin infrastructure projects.

Action items

None this week.


  • LN fee ransom attack: René Pickhardt publicly
    a vulnerability to the Lightning-Dev
    mailing list that he had previously privately disclosed to LN
    implementation maintainers almost a year ago. In the current LN
    protocol, each time the channel state is updated, the party who
    initiated opening the channel must commit to paying any onchain
    transaction fees for the unilateral close transaction. The party
    paying the fees also gets to choose the feerate used—but the
    counterparty’s security also depends on the feerate being appropriate. That
    means the counterparty may close the channel at any time if they think
    the chosen feerate has become too low for current market conditions.
    To avoid such unnecessary closes, BOLT2 gives an example of the
    fee-paying party selecting fees five
    times higher than the minimum reasonable estimate—high enough that
    the counterparty should be satisfied even if they’re using a
    different fee estimation algorithm.

    BOLT2 also allows channels to route up to 483 payments simultaneously, each of which requires a 43 vbyte P2WSH output, for a total of about 20,000 vbytes of data that needs to be added to the chain relatively quickly—meaning it may need to pay a high feerate. If that feerate is five times higher than strictly necessary, this can easily result in paying more than $100 USD in transaction fees at current bitcoin prices. Additionally, if the commitment transaction is confirmed, the HTLCs then need to be settled (again using time-sensitive transactions that may need to pay a high feerate). If the victim was the party routing those payments outbound, they’ll need to pay an additional transaction fee to recover each payment, which could make the attack two or three times more costly for them.

    Fees are paid to miners, so there’s no direct motivation to perform this attack, but if the attacker has the means to quickly contact the victim, it’s possible they can offer to settle the HTLCs offchain in return for a ransom, allowing the attacker to profit.

    Pickhardt concludes his email with several ideas for addressing the problem, none of which he finds completely satisfactory. The mitigation originally implemented in Eclair and later implemented in C-Lightning (see Newsletter #59) is for LN nodes to limit the number of pending payments, keeping transactions small and total fees low. Another mitigation in development is anchor outputs, which allow feerates to be selected when the channel is closed—eliminating the need to overestimate fees in order to prevent premature channel closures. Several other ideas are mentioned, but Pickhardt asks readers to contemplate the problem and suggest any other possible solutions.

  • Continued discussion about LN atomicity attack: Bastien Teinturier
    posted to the Lightning-Dev mailing list with a
    link to a detailed description of the LN commitment
    protocol, its weaknesses, and proposals to address those weaknesses.
    The document teaches readers everything they should need to know to
    understand the attack against LN atomicity described in Newsletter
    as well as several proposed mitigations. The
    document’s clear writing tied together several fragmented threads from
    previous discussions. This led to a renewed evaluation of several
    previously proposed solutions, including concerns about the
    effectiveness of the “alternative anchor proposal” and a suggested
    to use the pay-for-signature scriptless
    script to trustlessly pay a third party for the final signature needed
    to complete an adaptor signature.

  • Reminder about collision attack risks on two-party ECDSA:
    cryptographer Jonas Nick replied to the Bitcoin-Dev
    mailing list thread about a proposed CoinSwap implementation (see
    Newsletter #100) reminding developers that P2PKH,
    P2WPKH, and P2SH addresses which use the 160-bit RIPEMD160 hash are
    vulnerable to collision attacks that reduce its security to 80 bits
    when multiple parties collaborate to create an address using a naive
    protocol (see our description of this weakness
    in legacy P2SH addresses). Although this was previously only a
    concern for users of P2SH multisig, it applies in contexts, such as CoinSwap, where
    it’s proposed that two users could share a P2PKH or P2WPKH address.
    It’s possible to avoid this problem, but it requires that the
    two-party ECDSA protocol be designed to include an extra commitment
    procedure, which Nick notes some two-party ECDSA protocols and
    implementations already do.

Selected Q&A from Bitcoin StackExchange

Bitcoin StackExchange is one of the first places Optech
contributors look for answers to their questions—or when we have a
few spare moments to help curious or confused users. In
this monthly feature, we highlight some of the top-voted questions and
answers posted since our last update.

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,
C-Lightning, Eclair, LND,
Rust-Lightning, libsecp256k1,
Bitcoin Improvement Proposals (BIPs), and Lightning

  • Bitcoin Core #19260 disconnects peers that send the BIP37
    filterclear message if the local node isn’t accepting bloom filters
    (as advertised using the BIP111 NODE_BLOOM service flag). It
    was previously proposed that nodes starting in
    Initial Blockchain Download (IBD) could register as non-relaying peers
    to avoid receiving recent transactions while they were still
    downloading large numbers of blocks. When they finished syncing, they
    could then transition to receiving relayed transactions by sending a
    filterclear message. However, it was more recently
    proposed that this could be done instead using
    the BIP133 feefilter message. That eliminates any need for a
    non-bloom node to support the filterclear message and so this PR
    removes that feature.

  • Bitcoin Core #19133 adds a bitcoin-cli -generate parameter (note leading dash) to replace
    the functionality of the generate RPC, which was removed
    from Bitcoin Core in version The new
    implementation avoids unnecessary dependencies between the
    wallet and other components. Providing a client-side alias for the former RPC is useful for
    manual testing and makes it easier to update broken documentation.

  • Bitcoin Core #18027 adds two options to the GUI’s File menu for
    working with Partially Signed Bitcoin Transactions (PSBTs): Load PSBT from file and Load PSBT from clipboard. When
    one of those options is clicked and a PSBT is loaded, a dialog is
    provided that allows the user to sign an incomplete PSBT if this
    wallet has its key, broadcast a complete PSBT, or copy or save the
    PSBT for processing with another tool such as HWI. Combined with
    other recent PSBT-related GUI changes (see Newsletters #74 and #82) and HWI’s own GUI, this
    makes it possible to use a PSBT-based process with Bitcoin Core for
    the first time without using any RPCs.

    Screenshot of PSBT dialog in Bitcoin Core GUI

  • Bitcoin Core #16377 updates the walletcreatefundedpsbt and
    fundrawtransaction RPCs. These RPCs normally use the wallet to
    automatically choose which UTXOs to spend in an unsigned transaction,
    but they also allow the user to specify one or more UTXOs they want to
    spend in that transaction. Previously, if the UTXOs selected by the
    user weren’t enough to pay for all of the transaction’s outputs, the
    wallet would automatically select more UTXOs to spend. But, if a
    user is manually selecting UTXOs, they may have some reason they don’t
    want to spend additional UTXOs, so the RPCs will now fail by default
    if the user manually selects any UTXOs. This default may be overridden
    using the new add_inputs parameter to both RPCs.

  • Eclair #1461 adds several API endpoints that forward to Bitcoin
    Core RPCs for relaying that program’s wallet balances and other
    information. The goal is to make it easier to integrate Eclair with
    the Ride The Lightning node management dashboard.

  • Bitcoin Core #19071 adds documentation describing how developers
    can contribute to the new and experimental Bitcoin Core GUI
    . Pull requests related to the GUI should be made into
    this new repository, which will be bidirectionally synced with the
    main repository using
    the monotree development model used by the Linux Kernel Project.
    There are no direct user-visible changes from this split—users will
    still receive the GUI in the official packaged versions of Bitcoin Core or
    when building using --with-gui from the source code in the main

    Illustration of monorepo versus monotree

    This split is an experiment designed to determine whether using different repositories for different subsystems will help people interested in a particular subsystem focus on that part of the project. For example, someone using the GitHub Watch Repository feature will receive fewer issue and PR status updates each day when watching the Bitcoin Core GUI repository rather than the main repository, making it easier for them to monitor the project. Conversely, developers watching the main project, who may not all be interested in the GUI, will no longer need to receive notifications about it. In the best case, it’s hoped that this improved focus can speed up development, which may lead to discussion about creating monotree repositories for other subsystems. In the worst case, it’s feared the split could slow down development—but, if that happens, the experiment can be easily terminated and development can return to using a single repository (monorepo).

—Source link—

What do you think?

Annotations for the latest Week in Eth News

Centre Announces Multi-Chain USDC Framework