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
- ● 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
invmessages, 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.
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.
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
- ● 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
● C-Lightning #4020 adds a new
hook that will be called each time a channel changes state, such as
going from the “normal” operational state to “shutting down” when
● C-Lightning #3763 adds a
multifundchannelRPC 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
● 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
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.