Bitcoin Optech #158: Why Wallets Should Wait Before Generating Taproot Addresses

The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter describes recent changes to services and client software, discusses why wallets should wait before generating taproot addresses, lists new software releases and release candidates, and summarizes notable changes to popular Bitcoin infrastructure software.

News

No significant news this week.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

• Lightning-powered news site Stacker News launches: Open source news site Stacker News launched allowing LNURL authentication as well as voting and commenting using LN micropayments.

• Suredbits announces DLC wallet alpha release: Suredbits’ bitcoin-s software includes a GUI and allows the execution of Discreet Log Contracts (DLCs) on the Bitcoin blockchain using an oracle. The announcement concludes by mentioning they also plan to use schnorr signatures and Point Time Locked Contracts (PTLCs) to implement DLCs compatible with LN.

• Sparrow 1.4.3 supports P2TR: Sparrow’s 1.4.3 release supports single-sig P2TR wallets on signet and regtest. The release also supports sending to bech32m addresses for P2TR.

• Coldcard Firmware adds Seed XOR feature: Coldcard’s 4.1.0 Firmware supports Seed XOR, a way to split/combine BIP39 seeds in which each part can function as its own wallet. The combined, XOR’d, parts also function as a wallet. This allows for features like honeypot funds and plausibly deniability.

• BlueWallet integrates Lightning Dev Kit: BlueWallet announced a shift to a new Lightning implementation, now using Lightning Dev Kit (LDK).

Preparing for taproot #5: why are we waiting?

A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

Earlier entries in this series saw us encouraging developers working on wallets and services to begin implementing taproot upgrades now so that they’re ready when taproot activates. But we’ve also warned against generating any addresses for P2TR before block 709,632 as this could cause your service or your users to lose money.

The reason not to generate addresses in advance is that any payment to a P2TR-style output can be spent by anyone prior to block 709,632. The money would be completely unsecured. But starting with that block, thousands of full nodes will begin enforcing the rules of BIP341 and BIP342 (and, by association, BIP340).

If it was guaranteed that there wouldn’t be a reorganization of the block chain, it would be safe to start generating addresses for P2TR as soon as the final pre-taproot block was seen (block 709,631). But there’s reason to be concerned about block chain reorgs—not just accidental reorgs but also those deliberately created to take money from early P2TR payments.

Imagine a large number of people all wanting to be one of the first to receive a P2TR payment. They naively send themselves some money as soon as they see block 709,631.1 Those payments will be secure in block 709,632, but they can be stolen by any miner who creates an alternative to block 709,631. If the value of the money sent to P2TR outputs is large enough, it could easily become more profitable to attempt to mine two blocks instead of just one (see our fee sniping topic for more details).

For this reason, we don’t recommend your software or service generate addresses for P2TR until you think the reorg risk has been effectively eliminated. We think waiting 144 blocks (approximately one day) after activation is a reasonably conservative margin that minimizes risk without significantly delaying you or your users from taking advantage of the benefits of taproot.

In short:

• 709,631: last block where anyone can spend money sent to a P2TR-style output

• 709,632: first block where P2TR outputs can only be spent if they satisfy the BIP341 and BIP342rules.

• 709,776: a reasonable block at which wallets can start giving their users bech32m receiving addresses for P2TR outputs

None of the above changes the advice given in the first part of this series to enable paying to bech32m addresses as soon as possible. If someone requests payment to an address for P2TR before you think it’s safe, that’s their risk to take.

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.

• LND 0.13.1-beta is a maintenance release with minor improvements and bug fixes for features introduced in 0.13.0-beta.

• Rust-Lightning 0.0.99 is a release with a few API and configuration changes. See its release notesfor details.

• Eclair 0.6.1 is a new release with performance improvements, a few new features, and several bug fixes. In addition to its release notes, see the descriptions of Eclair #1871 and #1846 in the notable changes section below.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

• Bitcoin Core #22112 changes the assumed port for I2P addresses to be 0 instead of 8333 (which is the default for IPv4 and IPv6 addresses), and prevents connections to I2P addresses with ports other than 0. The SAM v3.1 specification (which is supported by Bitcoin Core), does not include the concept of ports. This restriction may be lifted if Bitcoin Core is updated to support SAM v3.2, which does include the concept of ports.

• C-Lightning #4611 updates the plugin-provided keysend RPC to add a routehintsparameter which allows providing information for routing payments to unannounced channels.

• C-Lightning #4646 makes two changes in preparation for removing old behavior. The first change assumes nodes support the TLV-style encoding added in 2019 (see Newsletter #55). Only nodes that explicitly indicate they don’t support TLV encoding will be treated differently. The second change makes payment secrets required (see Newsletter #75 for previous discussion and Newsletter #126 for when LND began requiring it).

• C-Lightning #4614 updates the listchannels RPC with a new optional destinationparameter that can be used to only return channels that lead to the requested node.

• Eclair #1871 changes its SQLite settings to increase by 5x the number of HTLCs it can process per second and also increase its robustness against data loss. Referenced in the PR is a blog postby Joost Jager comparing HTLC throughput in various node software.

• Eclair #1846 adds opt-in support for using an upfront shutdown script—an address the node specifies when negotiating a new channel that the remote peer agrees will be the only address it’ll allow to be used in a later mutual close of the channel. See also Newsletter #76 describing LND’s implementation of this feature.

• Rust-Lightning #975 makes the base payment forwarding fee configurable with a default value of 1 satoshi (the market rate as of July 2021). LN routing nodes can charge two fees to route a payment, a fixed base fee or a percentage of the amount routed; many nodes use both. Previously, Rust-Lightning set the base fee to the estimated fee required to settle the HTLC on-chain, which was much higher than 1 sat.

• BTCPay Server #2462 makes it easier to use BTCPay to track payments made from a separate wallet, such as the case where the operator of an instance wants to pay a refund using their own personal wallet.

Footnotes

• Users who want to receive a P2TR payment in the first taproot block should generate an address they don’t share with anyone and then create a transaction to that address with nLockTime set to 709,631. That transaction can be broadcast as soon as block 709,631 has been received. The nLockTime will ensure the transaction can’t be included into any block before 709,632, where taproot rules are enforced. Messing about with new script types and custom locktimes can be dangerous if you don’t know what you’re doing, so please take care.

Find the original post here.

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.

Good Griefing: A Lingering Vulnerability On Lightning Network That Still Needs Fixing

What happens when your Lightning Network routing node is fed with garbage transactions that never resolve? In short, it causes a lot of grief for routing nodes. What was once a smooth, global payment system can be locked up with trivial effort from a savvy script writer.

Working in a small team of routing nodes, we successfully ran a test of the attack with real funds and demonstrated the “griefing” attack described by Joost Jager. The attack is called a grief attack since it is not a theft of funds, but it causes a victim’s Lightning funds to be frozen: a major upset. What we found is that griefing is a serious threat to large “wumbo” channels expecting to earn a yield on their bitcoin, only to have their funds frozen for a period of time. 

This is mostly a grief attack: no loss of funds, but the victim may be forced to pay for an expensive channel force close. This is a known vulnerability on mainnet Lightning and it needs to be understood and prioritized, especially at this early market stage of Bitcoin’s Lightning Network.

Thanks to Clark Burkhardt and Phillip Sheppard for their willingness to participate in this test and to Jager for his tireless work to bring attention and priority to this vulnerability. Jager played the role of the attacker for our demonstration, while Burkhardt and Sheppard joined me as connected victim routing nodes.

How The Attack Works

The attacker saturates one (or several) channel(s) with Hashed Time Locked Contracts (HTLCs) that don’t resolve as a finalized payment. These are a special breed of HTLCs known as HODL invoices. Only 483 of these unresolved HTLCs are required to overwhelm a channel per direction. Once those HTLCs are in the channel, any transactions using that same channel direction are impossible, including a transaction to cooperatively close that channel.

In theory, an attacker could contact the victim (perhaps via a keysend message or in an “onion blob”) and demand a ransom be paid to halt the attack. Once the ransom is paid, the attacker could remove the unresolved payments, ending the attack. The attack can be sustained indefinitely, halting all routing and payment activity in that channel. This freezes the funds in the Lightning channel.

Both directions of payments can be stalled in a channel by using 483 HTLCs in each direction, both inbound and outbound.

Why Would An Attacker Do Something Like This?

The first motive that comes to mind is to demand a ransom. This attack causes pain for the victim and paying a ransom may be attractive to a victim, even without assurance that the attack would stop. Contacting the victim might be risky for an attacker, but a ransom payment might not be the only reason someone would do this.

A secondary incentive for launching a griefing attack would be to disrupt routing competition. Jamming a competitor’s route could create more demand for a route owned by an attacker.

As a benchmark, consider that Lightning Labs’ Loop node has an ongoing demand for liquidity for which it will sometimes pay a 2,500 parts per million of the payment (ppm) (0.25 percent) fee rate. In my experience, they would normally exhaust 16 million sats’ worth of liquidity in about two weeks (5.2 percent annual percentage rate), but that is with competition present. 

If an attacker could disable any competing route with lower fee rates, Loop may be willing to pay a higher fee rate (since the supply of liquidity is now reduced). Let’s say Loop would pay 3,000 ppm (0.3 percent), as well as use that liquidity more quickly since no other channels are functioning. Loop might use that liquidity in half the time, say one week. The attacker would more than double their usual yield to 15.6 percent APR in this example. The only cost to the attacker is the cost of running a script on an existing channel and the psychological cost of doing something immoral/damaging to the Lightning Network. With a single attacker channel, a malicious actor could jam about nine channels (see Jager’s tweets about this).

What Would The Victim Of This Attack Experience?

The victim of this attack wouldn’t really know that this attack was happening unless they had some special alerts set for pending HTLCs. For Thunderhub users (a highly recommended tool), the home screen will show a chart of pending HTLCs as well as a warning stating that channels can only hold 483 pending HTLCs.

In practice, my node quickly became unreliable and experienced several app crashes, including Thunderhub, which was the only app to notify me of the problem. Then, thanks to my “Balance of Satoshis” Telegram bot, I got a channel closing notification. The channel under attack force-closed itself! That was not supposed to be part of the experiment. (For more technical information on the involuntary force close, see below for additional force-close data.)

What Can The Victim Do To Stop A Griefing Attack?

Once an attack starts, a victim essentially can’t do anything to stop it. The only alternatives available to halt an ongoing attack would be to force-close the channel being attacked, which means that the terrorists win. 

To add insult to injury, force-closing the channel will push the unresolved payments to the on-chain transaction data, triggering secondary on-chain transactions for the initiator of the force close. At 50 sats/vbyte and 483 on-chain transactions, that’s easily a 1 million sat price tag to force close a single channel under attack (a $368 channel close fee at today’s prices). The multiple on-chain transactions only occur if the output is above the minimum payment “dust” limit. (See this example on testnet.)

The initiator of a Lightning channel pays the closing fee.

Another reason why you may not want 483 (non-dust) htlcs is that a potential force-close transaction at 50 sat/vB looks like this: https://t.co/z6mAGZxvrC.

The closing fee is getting expensive at over 1 million sat.

— Joost Jager (@joostjgr) September 28, 2020

How To Prevent A Griefing Attack

Jager has been working on a proof-of-concept program to help isolate and fight attackers. He’s calling his program “Circuitbreaker.” The Circuitbreaker works at a network level, which unfortunately means that everyone has to participate for it to be effective.

Beyond that, this issue needs prioritization and attention from dedicated engineers/developers to find better solutions. There have also been some good discussions on modifying the protocol in the Bitcoin Optech newsletter (issue #122 or #126).

This attack can be executed today. It is a miracle that it hasn’t already been used maliciously. It’s a reflection of the incentives for those using Lightning today so that it can become an open, universal payment network. Please share this post as you see fit to encourage and inspire more work to fix this problem before it causes real harm.

Additional Technical Information About The Involuntary Force-Close

Here are the logs from my node running LND 0.11 at the moment that the above mentioned involuntary force-close occured:

2020-11-26 21:24:47.374 [ERR] HSWC: ChannelLink(657759:561:0): failing link: ChannelPoint (c37bec006b18df172698a84739ca47128935e0a8666fecd1a843e49b01db207c:0): received error from peer: chan_id=7c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc3, err=rejected commitment: commit_height=455, invalid_commit_sig=3044022076fd65191eb6305b723fa6012be378413b6326e2786c38db58b4c02e1f3999d202207605ca31de8b4c5b1d9cd20dc1581dfa2383e0b4e06c8ad4f718ab5c434d8cf5, commit_tx=02000000017c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc300000000008a792e8002210d0000000000002200201031cf10a1efef261edd3d0a1a6a953b27bc25bd7150bb2b07afdc69805e02157213000000000000160014de650929042bef58b71783ae1a44834a902a8f2d542ca720, sig_hash=4e0fb804c74376020e4c44a60969b9206eb0aaa9a89b76017d60f23ad5cf63e5 with error: remote error

The logs show an “invalid_commit_sig” which is a known issue in LND. Supposedly, this can happen upon reconnecting and isn’t a direct result of the channel jamming. The volume of pending HTLCs unfortunately makes it more likely to happen. Jager helped explain the process as channel jamming –> endless payment loop (bug) –> node down –> reconnect –> invalid commit sig (bug) –> channel force-close.

The “endless” loop bug is a known bug that occurs when the HTLC limit is reached and an additional HTLC is sent. Instead of ending in a payment failure, LND will continue to attempt the payment in a loop. To help with this bug, see LND issue #4656.

This is a guest post by Jestopher. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.