<p>This November 2022 bug is very similar to the October 2022 bug. This time it impacted a number more open source projects (e.g. <a href="https://twitter.com/Liquid_BTC/status/1587499305664913413?s=20&amp;t=8rDtx1gFy5DLHf2hBTqvmQ" rel="nofollow noreferrer"> Liquid</a> and <a href="https://twitter.com/lightningdevkit/status/1587939344530145280?s=20&amp;t=8rDtx1gFy5DLHf2hBTqvmQ" rel="nofollow noreferrer">LDK</a>) as rust-bitcoin also wasn't able to deal with the <a href="https://blockstream.info/tx/73be398c4bdc43709db7398106609eea2a7841aaf3a4fa2000dc18184faa2a7e" rel="nofollow noreferrer">transaction</a> 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).</p>
<p>Burak explained the source of the bug <a href="https://github.com/btcsuite/btcd/issues/1906" rel="nofollow noreferrer">here</a>:</p>
<blockquote>
<p>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.</p>
<p>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:
<a href="https://blockstream.info/tx/73be398c4bdc43709db7398106609eea2a7841aaf3a4fa2000dc18184faa2a7e" rel="nofollow noreferrer">https://blockstream.info/tx/73be398c4bdc43709db7398106609eea2a7841aaf3a4fa2000dc18184faa2a7e</a></p>
<p>Changing the maxWitnessItemsPerInput parameter from 500,000 to 4,000,000 solves the issue:
<a href="https://github.com/btcsuite/btcd/blob/master/wire/msgtx.go#L103" rel="nofollow noreferrer">https://github.com/btcsuite/btcd/blob/master/wire/msgtx.go#L103</a></p>
</blockquote>
<p>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 <a href="https://github.com/btcsuite/btcd/pull/1907" rel="nofollow noreferrer">PR</a>. The <code>maxWitnessItemsPerInput</code> was previously only <code>500,000</code> and needed to be bumped to <code>4,000,000</code> to meet the Taproot consensus rules. Why it was previously <code>500,000</code> is unclear. As Pieter says in the comment:</p>
<blockquote>
<p>The 500000 value was always wrong as a limit, since Segwit has existed. BIP141 even spells this out explicitly: &quot;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.&quot;. It couldn't be triggered using standard transactions, but that's still the case with taproot.</p>
</blockquote>
<p>In terms of who is impacted the answer is very similar to what was stated in October 2022's <a href="https://bitcoin.stackexchange.com/questions/115527/what-is-the-october-2022-bug-in-lnd-what-caused-it-and-what-would-prevent-a-sim">answer</a> with the exception that this time LDK is impacted also. Core Lightning and eclair are not impacted:</p>
<blockquote>
<p>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.</p>
</blockquote>

CC BY-SA 4.0
2022-11-03T13:03:50.947Z
@1440000bytes: Thanks. At least on the Sparrow side it shouldn't represent a funds security risk just a crash risk.
Michael Folkson
CC BY-SA 4.0
2022-11-03T16:03:47.000Z
FWIW, 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.
Pieter Wuille
CC BY-SA 4.0
2022-11-03T12:18:28.430Z
2022-11-06T00:02:30.940Z
2022-11-06T00:02:30.940Z
Michael Folkson
<p>LND users are <a href="https://twitter.com/lightning/status/1587443868617818113?s=20&amp;t=8rDtx1gFy5DLHf2hBTqvmQ" rel="noreferrer">being asked</a> as of November 2022 (as they were in <a href="https://bitcoin.stackexchange.com/questions/115527/what-is-the-october-2022-bug-in-lnd-what-caused-it-and-what-would-prevent-a-sim">October 2022</a>) 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?</p>

<security><lightning-network><lightning-network-daemon><taproot><watchtower>
What is the November 2022 bug in LND, what caused it and what would prevent a similar bug in future?
Michael Folkson
# What is the November 2022 bug in LND, what caused it and what would prevent a similar bug in future?

(Asked by: username_0 on 2022-11-03)

LND users are [being asked](https://twitter.com/lightning/status/1587443868617818113?s=20&t=8rDtx1gFy5DLHf2hBTqvmQ) as of November 2022 (as they were in [October 2022](https://bitcoin.stackexchange.com/questions/115527/what-is-the-october-2022-bug-in-lnd-what-caused-it-and-what-would-prevent-a-sim)) 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?

**Tags:** security, lightning-network, lightning-network-daemon, taproot, watchtower


---

## 1 answers

### Answer by username_0 on 2022-11-03. Score: 3 | Accepted answer

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](https://twitter.com/Liquid_BTC/status/1587499305664913413?s=20&t=8rDtx1gFy5DLHf2hBTqvmQ) and [LDK](https://twitter.com/lightningdevkit/status/1587939344530145280?s=20&t=8rDtx1gFy5DLHf2hBTqvmQ)) as rust-bitcoin also wasn't able to deal with the [transaction](https://blockstream.info/tx/73be398c4bdc43709db7398106609eea2a7841aaf3a4fa2000dc18184faa2a7e) 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](https://github.com/btcsuite/btcd/issues/1906):

> 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](https://github.com/btcsuite/btcd/pull/1907). 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 username_1 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](https://bitcoin.stackexchange.com/questions/115527/what-is-the-october-2022-bug-in-lnd-what-caused-it-and-what-would-prevent-a-sim) 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.

> **Comments:**
> **username_0**: @1440000bytes: Thanks. At least on the Sparrow side it shouldn't represent a funds security risk just a crash risk.  
> **username_1**: FWIW, 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.  

---

