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.

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.

  

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

—Source link—