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.

News

  • ● 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 (BIPs), 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 transaction.

  • ● 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 getinfo, a user may create a profile and then use just lncli -p test getinfo. 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.