What is the November 2022 bug in LND, what caused it and what would prevent a similar bug in future?

Question

LND users are being asked as of November 2022 (as they were in October 2022) to urgently update their Lightning node software due to a bug in LND/btcd (alternative Bitcoin implementation in Go). What is the bug and what caused it? Who will it impact and will they potentially lose money? How would a similar bug be prevented in future?

Answer 1

This November 2022 bug is very similar to the October 2022 bug. This time it impacted a number more open source projects (e.g. Liquid and LDK) as rust-bitcoin also wasn't able to deal with the transaction that Burak broadcast. As before the transaction met the Taproot consensus rules activated on the network in November 2021, was included in a block by F2Pool (it seems it was submitted directly to F2Pool as the transaction doesn't meet current default policy rules in Bitcoin Core nodes) and was verified by all Bitcoin Core full nodes (but not btcd and rust-bitcoin).

Burak explained the source of the bug here:

Bitcoin has a consensus rule that limits the number of stack items in a row to 1000. However, a P2TR spend containing OP_SUCCESSx precedes this rule regardless.

I made a P2TR spend containing an OP_SUCCESSx opcode with 500,001 empty pushes, which as a result, caused a consensus conflict between btcd and core: https://blockstream.info/tx/73be398c4bdc43709db7398106609eea2a7841aaf3a4fa2000dc18184faa2a7e

Changing the maxWitnessItemsPerInput parameter from 500,000 to 4,000,000 solves the issue: https://github.com/btcsuite/btcd/blob/master/wire/msgtx.go#L103

The relevant line of code is the line above the line that caused the October 2022 bug (thanks AJ for initially pointing this out). It was fixed by Elle Mouton in this PR. The maxWitnessItemsPerInput was previously only 500,000 and needed to be bumped to 4,000,000 to meet the Taproot consensus rules. Why it was previously 500,000 is unclear. As Pieter says in the comment:

The 500000 value was always wrong as a limit, since Segwit has existed. BIP141 even spells this out explicitly: "If the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack.". It couldn't be triggered using standard transactions, but that's still the case with taproot.

In terms of who is impacted the answer is very similar to what was stated in October 2022's answer with the exception that this time LDK is impacted also. Core Lightning and eclair are not impacted:

With regards to who it will impact and whether they will lose money, this depends on the LND user, on whether channel counterparties seek to exploit this bug and how quickly users are able to update to LND v0.15.2. Other Lightning node implementations (Core Lightning, eclair, LDK etc) are unaffected. If the LND node is backed by a btcd full node then the btcd full node will also need updating. There are two ways this bug could be exploited if LND users aren't able to update speedily. Channel counterparties could broadcast a revoked state and unless the LND node comes back up within 2 weeks or an external watchtower is employed money could be lost this way. In addition if the LND node is a routing node money could be lost by its inability to close a channel if HTLC hash preimage(s) are not provided by channel counterparties prior to the timeout.