Bitcoin Optech Newsletter #115 Bitcoin Optech

This week’s newsletter recommends checking for nodes vulnerable to the
InvDoS attack, briefly describes that attack, summarizes another attack
against LN channels, and links to the announcement of the Crypto Open
Patent Alliance. Also included are our regular sections with releases,
release candidates, and notable changes to popular Bitcoin
infrastructure projects.

Action items

  • Check for nodes vulnerable to the InvDoS attack: an attack
    disclosed this week affects several old versions of full node software
    (including altcoins). According to the paper,
    affected Bitcoin software includes “Bitcoin Core v0.16.0, Bitcoin Core
    v0.16.1, Bitcoin Knots v0.16.0, all beta versions of bcoin up to
    v1.0.0-pre, [and] all versions of btcd up to v0.20.1-beta.” The
    latest released versions of Bitcoin Core, Bitcoin Knots, bcoin, and
    btcd all contain fixes. See the News section below for details.


  • Inventory out-of-memory Denial-of-Service attack (InvDoS): Braydon
    Fuller and Javed Khan posted to the Bitcoin-Dev mailing
    list an attack (website, paper,
    CVE-2018-17145) they’d previously disclosed to the
    maintainers of various Bitcoin and Bitcoin-derived full nodes. The
    attack consisted of inv (inventory) messages Bitcoin nodes use to
    notify their peers of the hash of new transactions (or other data).
    Normally, when a peer receives an inventory, it checks to see if it
    already has a transaction with that hash and then requests full copies
    of any previously-unseen transactions. In the attack, an attacker would flood the
    victim with an excessive number of inv messages, each containing
    nearly the maximum allowed number of transaction hashes. When too
    many of these inventories were queued, the victim’s node would run out
    of memory and crash.

    Several of the affected programs had code that limited the number of inventories that should’ve been queued, but the researchers were able to circumvent those protections. As a bug that could only crash nodes, it could not be used to directly steal from affected nodes. However, it could be used to execute eclipse attacks that could ultimately steal money—although there’s no indication the attack was ever used in public.

    All users are encouraged to upgrade to the latest released version of their preferred full node software or to review the list of vulnerable and patched versions on the website.

  • Stealing onchain fees from LN HTLCs: Antoine Riard posted to the Lightning-Dev mailing list a potential vulnerability in a
    recent update to the LN specification (see Newsletter #112). When LN payments are made according to the updated
    specification, each remote party includes a flag in the signature for
    their half of the 2-of-2 multisig script. The flag, called
    SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, allows the payment (called an
    HTLC) to be placed into a transaction containing other inputs and
    outputs. This is designed to allow multiple HTLCs to be bundled
    together into a transaction that also contains an extra input that
    pays any additional transaction fees and an optional extra output that
    collects any money left over from paying those extra fees. This makes
    it possible to wait until those HTLCs need to be confirmed before
    choosing what feerate to pay.

    Spending HTLCs with a fee-bumping input and a change output

    However, Riard notes that the specification’s earlier mechanism of committing to variable feerates for HTLCs is still available. This can allow an attacker to commit to a high fee for multiple HTLCs and then construct a transaction that combines those HTLCs with just an additional output that claims some of the funds expected to be used as fees. Riard’s email describes how to use this basic technique in a more complex attack to maximize the amount stolen.

    Using a change output to steal fees from HTLCs that overpay fees

    Several solutions were proposed, the simplest of which might be to have HTLCs only pay a minimal relay fee—requiring the party broadcasting the HTLCs add any additional necessary fees. No LN implementation defaults to using this recent specification update yet, so only users who have played with experimental options related to anchor outputs should be affected.

  • Crypto Open Patent Alliance: Square announced the
    formation of an organization to coordinate the pooling of patents
    related to cryptocurrency technology. Members allow anyone to use
    their patents freely and, in exchange, receive the ability to use
    patents in the pool in defense against patent aggressors. In addition
    to Square, Blockstream also announced it is
    joining the pool.

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.

  • C-Lightning 0.9.1 is the a new release that
    contains a number of new features and bug fixes, including all the new
    capabilities described in the following notable changes section.
    See the project’s release notes for details.

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.

  • C-Lightning #4020 adds a new channel_state_changed notification
    hook that will be called each time a channel changes state, such as
    going from the “normal” operational state to “shutting down” when
    being closed.

  • C-Lightning #3812 adds a multiwithdraw RPC that allows sending
    funds onchain to multiple addresses for payment batching.

  • C-Lightning #3763 adds a multifundchannel RPC that allows
    funding several channels at the same time using a single deposit
    transaction with multiple outputs. This can save 75% or more on
    transaction fees due to the efficiency advantage of payment batching.
    As an experiment, this new feature was used to open a channel to
    every functional and publicly listed LN node on testnet in a single

  • C-Lightning #3973 adds support for the accepter side of dual-funded
    channels. These are channels where both participants contribute funds
    rather than just a single initiator contributing funds (see
    Newsletters #22 and #83). The initial implementation of the opener side
    is still being worked on, although there’s a draft of the related specification changes.

  • C-Lightning #3870 implements a scorched earth fee bumping
    mechanism for penalty transactions. If the remote peer broadcasts an
    old channel state, the local node can use the corresponding revocation
    key to create a penalty transaction that spends all of the funds
    claimed by the non-compliant peer. To avoid this, the peer might
    attempt to bribe miners to ignore the honest node’s penalty
    transaction. With a scorched earth policy, the honest node
    fee bumps its penalty transaction so that it pays its entire value to
    fees—ensuring the non-compliant peer does not profit from its
    attempted theft. In theory, if thieves know they cannot profit from
    an attack, they won’t try it. This PR seems to have been
    inspired by a Lightning-Dev mailing list
    discussion in July, see Newsletter #104.

    The implementation of the scorched earth policy C-Lightning uses is to periodically fee bump the penalty transaction, eventually replacing it with a transaction that spends all of its value to fees. Anyone else implementing a similar policy may want to review this code for the way it addresses subtle potential issues such as minimum transaction sizes (see Newsletter #99) and a year-old change to a maximum fee API in Bitcoin Core (see Newsletter #39).

  • LND #4310 adds the ability to create and use profiles with
    lncli. A profile automatically applies its saved parameters to all
    connections, making it useful for people who always use the same
    non-default parameters or who connect to multiple servers. For
    example, instead of calling lncli --rpcserver=10019 --network=regtest
    , a user may create a profile and then use just lncli -p test
    . The PR additionally allows LND’s authentication credentials
    (“macaroons”) to optionally be stored in the profile using encryption.

  • LND #4558 updates LND’s existing anchor outputs implementation to match the latest version of the
    specification, merged three weeks ago (see Newsletter #112). It also removes anchor outputs from the set of experimental features
    with the plan to make it enabled by default in the next major release
    of LND.

  • Rust-Lightning #618 adds C/C++ bindings support for rust-lightning. This
    provides a framework that can be used to create APIs in other languages
    such as Swift, Java, Kotlin, and JavaScript.
    The approach chosen results in a more performant and memory-efficient method than
    alternatives such as JSON or RPC, which is particularly important on mobile and
    limited-resource environments. See the bindings documentation for more details.

  • Libsecp256k1 #558 implements schnorr signature
    verification and single-party signing over the secp256k1 elliptic curve as
    standardized in BIP340. Compared to the existing ECDSA signatures used in
    Bitcoin, schnorr signatures rely on fewer security assumptions, are
    non-malleable, and allow for much simpler key aggregation schemes such as
    MuSig. Schnorr signatures are also a key component of
    taproot, which uses aggregated schnorr signatures for “everyone
    agrees” key-path spends. Spending a taproot output using the key-path offers
    better spending condition privacy and reduces signature sizes. Bitcoin Core
    has correspondingly updated their internal libsecp256k1 tree to
    incorporate this change.

—Source link—

What do you think?

How Ethereum Smart Contracts Power Dai, the Maker Protocol, and DeFi The Maker Blog

DeFi x NFTs = NFTfi Token Tuesdays