This week’s newsletter links to a blog post and paper about using
eclipse attacks against Bitcoin software in order to steal from LN
channels and describes the history and impact of a fee overpayment
attack that affects hardware wallets. Also included are our regular
sections with the summary of a Bitcoin Core PR Review Club meeting,
descriptions of recent software releases, and summaries of recent
changes to popular Bitcoin infrastructure projects.
Action items
- ● Check hardware wallet compatibility: if your software or your
processes allow using hardware wallets to spend segwit inputs, check
whether your system remains compatible with your wallet’s latest
firmware update. For example, Trezor’s latest firmware requires software interfacing with it to be upgraded to
continue handling segwit inputs; Ledger’s latest firmware will
print a warning when processing segwit inputs received from
non-updated software. Other hardware wallets may release similar
updates in the future; contact the manufacturers for more information
about their plans. See the News item below about the fee
overpayment attack for the motivation for this change.
News
-
● Time dilation attacks against LN: Gleb Naumenko and Antoine Riard
posted to the Bitcoin-Dev mailing list a summary of a
blog post they wrote that itself summarizes a paper they authored about using eclipse attacks
to steal money from LN channels. This extends the analysis by Riard
described in Newsletter #77. In short, an attacker
gains control over all of an LN node’s connections to the Bitcoin P2P
network and delays the relay of new block announcements to the victim.
After the victim’s view of the block chain is far enough behind the
public consensus view, the attacker closes their channels with the
victim in an outdated state that pays the attacker more than the
latest state would. The eclipse attack is used to prevent the victim
from seeing the close transactions until after the dispute period is
over and the attacker has withdrawn their illicit gains to an address
entirely under the attacker’s control.The paper describes an attack that can steal from lightweight clients in as little as two hours. With there currently being so few servers and nodes providing data to lightweight LN clients, it may be fairly easy for an attacker to create enough sybils to execute the attack. Attacks against LN nodes backed by a local Bitcoin full verification node take longer—still only a matter of hours—and may require creating many more sybils. The authors note that the attacks probably also apply to other time-sensitive contract protocols. The general solution to the problem is to improve eclipse attack resistance, with one specific proposed improvement being to allow nodes to opt-in to alternative transport protocols.
-
● Fee overpayment attack on multi-input segwit transactions: The
fee paid by a Bitcoin transaction is the difference between
the amounts of the UTXOs the transaction spends and the amounts
of the UTXOs it creates. Transactions explicitly state the amounts
of the UTXOs they create, but the amounts of the UTXOs they spend can
only be found by looking at the previous transactions that created
those UTXOs. The spending transaction simply commits to the txid and
position of the UTXOs it wants to spend, requiring other software that
wants to calculate the fee to either look up each UTXO’s previous
transaction or to maintain a database of verified UTXO data.Hardware wallets don’t maintain a UTXO set, so the only trustless way for them to determine the amount of fee paid by a transaction with legacy UTXOs is to get a copy of each legacy UTXO’s previous transaction, hash the previous transaction to ensure its txid matches the UTXO reference, and use the now-verified amount of the UTXO to perform the fee calculation. In the worst case, legacy transactions can be almost as large as one megabyte and it’s possible for a spending transaction to reference thousands of previous transactions, so amount verification can require the processing of gigabytes of data by resource-constrained hardware wallets.
One of the several improvements made in BIP143 segwit v0 was an attempt to eliminate this burden by having signatures commit to the amount of the UTXO they were spending. This meant that any signatures that committed to an incorrect amount would be invalid, which developers of both Bitcoin Core and hardware wallets believed would allow signers to safely accept amounts from untrusted software.
Unfortunately, signing a single UTXO’s amount turned out to be insufficient. In 2017, Greg Sanders described an attack that can be used to trick a user into significantly overpaying their transaction fee. To start, an attacker takes control of the desktop or mobile software that interfaces with a hardware wallet and waits for the user to initiate a payment. The compromised software creates two variations of the requested transaction that each spend the same two segwit UTXOs controlled by the user’s attached hardware wallet. In the first transaction, the compromised software understates the amount of one of the UTXOs being spent. This will cause the hardware wallet to under-calculate the transaction fee by that same understated amount. In the second transaction, the compromised software understates the amount of the second UTXO. That will cause the hardware wallet to also under-calculate the second transaction’s fee.
The compromised software sends the first transaction to the hardware wallet. The user checks the amount, receiver address, and calculated transaction fee. The user authorizes signing and the signed transaction is returned to the compromised software. This first transaction is invalid under BIP143 because one of its signatures commits to an incorrect UTXO amount. The compromised software then claims that there was some minor problem that prevented the transaction from being broadcast and tells the user they need to re-sign the transaction, but the software doesn’t re-send the first transaction—it instead sends the second transaction. Based on the information displayed by the hardware wallet (amount, receiver, and fee), the second transaction looks identical to the first transaction, so it’s likely the user will authorize signing it. This second transaction is also BIP143 invalid because one of its signatures commits to an incorrect amount. However, each of the two transactions also had one valid signature and the compromised software is able to use those two valid signatures to synthesize a valid transaction that overpays its fees.
The worst case is an attack that prompts the user to sign n times for a wallet that controls n UTXOs and which results in spending all of the wallet’s funds to fees except for the legitimate payment amount.
Similar to the other attack described in Sander’s 2017 email (see Newsletter #97), this attack only affects stateless signers, such as hardware wallets, which depend on an external system to tell them about the UTXOs they control. Networked wallets which track the amounts of their received UTXOs won’t sign for incorrect UTXO amounts and so aren’t affected by this attack. Of course, networked wallets are vulnerable to other attacks, which is why hardware wallets can enhance user security.
This past week, Trezor announced that Saleem Rashid rediscovered this vulnerability about three months ago. In response, Trezor has updated its firmware to require copies of previous transactions for segwit UTXOs the same way it requires them for legacy UTXOs. This has broken compatibility with several wallets that interface with Trezor devices, either directly or through HWI (see HWI #340). In cases where wallets have full copies of the previous transactions or are able to obtain them, restoring compatibility should just be a matter of updating the wallet code. In other cases where wallets may not store full copies of previous transactions that paid the wallet, this may require redesigning the wallet to store that data plus require rescanning the block chain for past wallet transactions. Software that creates or updates Partially Signed Bitcoin Transactions (PSBTs) will need to be upgraded to include the full copies of previous transactions into the PSBTs. For cases where PSBTs are stored in size-constrained media (e.g., QR codes, see Newsletter #96), the potentially significant increase in data size may require abandoning the protocol or switching to higher-capacity media.
Ledger has made a similar change, but their support article says they only display a warning when spending segwit UTXOs without full copies of their previous transactions. Although requiring previous transactions does maximize user safety against this attack, there are also arguments for allowing hardware wallets to optionally continue to use segwit’s signed UTXO values rather than breaking existing software and expending additional resources on legacy-style value verification:
-
● Attack already well-known for three years: Sanders publicly
described the attack almost three years ago and it’s been
mentioned or alluded to by others on the mailing list, in BIPs, and in Newsletters
#11 and #46, among
other discussions. It was believed that
“everyone thought it was too hard to deal with, and only of
minimal impact”.
Any attacker who gains access to the software controller for
a hardware wallet is perhaps more likely to perform a different
attack—such as an address substitution attack—that pays the attacker directly rather than overpaying
transaction fees. -
● Double signing can also lead to spending twice: the attack
depends on using compromised software to get a hardware wallet
user to authorize two slightly different transactions (each with
two inputs) that look identical to the user. Yet the same
compromised software could show the user two completely different
transactions (each spending a different input) that look
identical, resulting in paying the same recipient twice. Both
attacks are indistinguishable from the user’s perspective, but the
fix for the fee overpayment attack doesn’t fix the spending twice
attack. -
● Multisig setups may require multiple compromises: to perform
the attack against funds secured by multisig with multiple
hardware wallets, each signer that is needed to meet the minimal
threshold (e.g., “2” in a “2-of-3” multisig) would need to be
tricked into signing the same two transaction variations. For
thresholds that include an online wallet which knows the value of
the UTXO it’s signing for (e.g., a policy-based remote signer), the
attack only works if that online wallet is also compromised.
A long-term solution to the attack is to change the transaction digest so that each signature commits to the value of all UTXOs being spent in that transaction. That will make the signature invalid if compromised software lies about the amount of any UTXO. This was proposed by Johnson Lau in 2018 (see Newsletter #11) and has been included in the BIP341 specification of taproot since its earliest public drafts (see Newsletter #46). If taproot is adopted, then it should become safer for stateless signers like hardware wallets to sign for taproot UTXOs without evaluating previous transactions. Unfortunately, that still doesn’t fix the spending twice attack, which is an issue with the stateless design of most hardware wallets that prevents them from internally tracking their own transaction history.
-
Bitcoin Core PR Review Club
In this monthly section, we summarize a recent Bitcoin Core PR Review Club
meeting, highlighting some of the important questions and answers. Click on a
question below to see a summary of the answer from the meeting.
Connection eviction logic tests is a PR (#16756) by Martin Zumsande that adds missing test coverage for part of the
Bitcoin network peer eviction logic. The test verifies that the inbound peers
which relay transactions and blocks, and which respond quickly, are protected from
eviction.
The discussion centered on eviction logic and the protection of inbound peer
connections in Bitcoin Core:
-
What does a Bitcoin Core node do when the number of inbound connections reaches the limit?
When the node connections are full, the node reacts to the connection of a new inbound peer by terminating the connection with an existing inbound peer. This is referred to as “eviction.”
-
Why does Bitcoin Core evict peers instead of no longer accepting new inbound connections?
The goal is to continuously select for well-behaved peers, from a variety of networks, that relay blocks quickly—and to prevent a malicious party from monopolizing the connection slots. The first connections to arrive aren’t necessarily the best ones, so an eviction mechanism is needed. ➚
-
Why does Bitcoin Core protect selected peers from eviction?
We want to keep connections that have proven to be useful and increase the difficulty for a malicious party to evict and occupy all the inbound connections. Therefore, a small number of peers are protected for each of several distinct characteristics which are difficult to forge. In order to partition a node, the attacker must simultaneously be better at all of them than honest peers. ➚
-
Describe the algorithm for inbound peer eviction in Bitcoin Core.
Select all inbound peers except those on the
NO BANlist or already scheduled for disconnection. Then, remove (protect) the best peers according to costly, difficult-to-forge attributes, which each apply separately: network group, lowest minimum ping time, recently sent transactions and blocks, desirable service flags, and long-lasting connections. Of the remaining peers, choose one to evict from the network group with the most connections. ➚
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.
-
● Bitcoin Core 0.20.0 is the newest major release from the original
Bitcoin project. This release’s most notable user-visible improvements
include default bech32 addresses for RPC users (the GUI began
defaulting to bech32 in 0.19), the ability to configure RPC
permissions for different users and applications (see Newsletter
#77), some basic support for generating PSBTs in
the GUI (#74 & #82), and a
sortedmultiaddition to the output script descriptor language that can make it easier to watch multisig
addresses generated from lexicographically sorted keys, such as those
used with Coldcard’s native multisig support (#68).Many less visible improvements have also been made to the code in order to eliminate bugs, enhance security, and prepare for future changes. One forward-looking change that’s attracted some attention is the addition of an
asmapconfiguration setting that allows using a separately downloaded database to improve Bitcoin Core’s ability to diversify its connections among networks controlled by many different groups, increasing its resistance to eclipse attacks such as the Erebus attack (see Newsletter #83). However, one of the authors of the feature notes, “it’s highly experimental for now, and unclear how to progress from that. Gathering and compiling the ASN [Autonomous Service Number] data is very nontrivial, and poses trust questions.”For more information about all the changes as well as a list of over 100 people who contributed to this new version, see the project’s release notes.
-
● LND 0.10.1-beta is a new minor release of this popular LN node
software. The release notes announce no major new features but
do mention several bug fixes, a “new dry run migration mode to test
out migrations before they’re applied permanently, and an enhancement
to the channel selection/restrictions in the router sub-server.”
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
BOLTs.
-
● Eclair #1440 makes it possible to use the API to update multiple channels at once. Proposed
initially to help node operators adjust to the dynamic on-chain fee market
by batch updating their channels’ relay fees, this addition enables batch
closing and force-closing as well. -
● Eclair #1141 adds support for
option_static_remotekeychannels.
In the case of data loss by an LN node, this feature allows the channel
counterparty to pay the current balance to an untweaked key agreed upon during the initial
channel open, closing the channel and allowing the node’s wallet to
spend its funds normally. See Newsletter #67 for
more details on this feature. -
● LND #4251 brings its REST interface’s list of supported non-streaming
messages to parity with that of its gRPC interface. Previously, only a subset
of these messages (specifically those of theLightningsubserver) were
available via the REST interface. This PR will be followed by LND
#4141, which brings the REST interface to full parity with the gRPC
interface by adding support for streaming responses with WebSockets. -
● BIPs #920 updates the BIP341 specification of taproot to require signatures to directly commit to the scriptPubKeys
of all the UTXOs being spent. This makes it easier for hardware
wallets to safely participate in coinjoins and other collaboratively
generated transactions. For details, see the description in
Newsletter #97.
Special thanks
We thank Pieter Wuille for assistance researching the history of the fee
overpayment attack. We thank Antoine Riard for additional information
about the time dilation attack paper. Any errors or omissions are the fault of the
newsletter author.