<p>There was a bug in LND and btcd which was exposed by a perfectly valid 998-of-999 Taproot multisig <a href="https://twitter.com/brqgoo/status/1579216353780957185?s=20&amp;t=0KZqWYXHZWnSYSFZSsodkA" rel="nofollow noreferrer">transaction</a> broadcast by Burak on October 9th 2022. This transaction met the Taproot consensus rules activated on the network in November 2021, was included in a block by a miner and verified by all Bitcoin Core full nodes (and as far as I know alternative implementations other than btcd).</p>
<p>(The transaction was analyzed <a href="https://gist.github.com/AdamISZ/9b2395ddcb43890d9611df99287cfe6b" rel="nofollow noreferrer">here</a> by AdamISZ.)</p>
<p>The Taproot consensus rule upgrade included in <a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#resource-limits" rel="nofollow noreferrer">BIP342</a>:</p>
<blockquote>
<p>Script size limit: The maximum script size of 10000 bytes does not apply. Their size is only implicitly bounded by the block weight limit.</p>
</blockquote>
<p>btcd full nodes rejected the transaction and the block the transaction was included in and its blockchain stalled. The btcd wire parsing library was still enforcing the maximum script size limit from SegWit version 0 for SegWit version 1 transactions.</p>
<p>This impacted all LND nodes (both those backed by a Bitcoin Core full node and those backed by a btcd full node) because the btcd wire parsing library that deserializes raw blocks is a LND dependency.</p>
<p>As Olaoluwa Osuntokun (LND, btcd maintainer) stated on Twitter:</p>
<blockquote>
<p>The issue was in btcd's wire parsing library that deserializes raw blocks, the initial implementation of segwit v0 included a consensus level check for witness size limits but <em>also</em> hoisted this check up to the wire parsing layer</p>
<p>With segwit v1, this prior limit of the max accepted witness size was removed, in place of things like the sigop cost abstraction, effectively leaving the limit to the max block weight/size</p>
<p>btcd's initial segwit v1 implementation correctly updated the consensus logic, but failed to also update the defense-in-depth check in the wire parsing layer (when parsing off the wire you want <em>some</em> sort of upper limit)</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 <a href="https://github.com/lightningnetwork/lnd/releases" rel="nofollow noreferrer">LND v0.15.2</a>. 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 <a href="https://github.com/btcsuite/btcd/pull/1896" rel="nofollow noreferrer">need updating</a>. 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>
<p>There was <a href="https://github.com/lightningnetwork/lnd/issues/7002" rel="nofollow noreferrer">further discussion</a> on why the Taproot (BIP341) static <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#Test_vectors" rel="nofollow noreferrer">test vectors</a> didn't catch the bug in the LND repo. Olaoluwa Osuntokun again:</p>
<blockquote>
<p>btcd is/was using this test vectors. The issue here is that the code the parsed the witnesses for these test vectors isn't the same code that's used to read blocks off the wire. When a new block comes in, we fetch the raw block then attempt to decode it, which triggered this issue.</p>
</blockquote>
<p>This bug was also covered in <a href="https://bitcoinops.org/en/newsletters/2022/10/19/#block-parsing-bug-affecting-btcd-and-lnd" rel="nofollow noreferrer">Bitcoin Optech</a>.</p>

CC BY-SA 4.0
2022-10-11T11:22:46.830Z
the root cause of the bug was that btcd still enforced pre-taproot script size limits. The bug was exposed by Burak's transaction, not caused by it
Alex
CC BY-SA 4.0
2022-10-11T11:23:48.033Z
@Alex: Indeed, will improve the wording. Thanks
Michael Folkson
CC BY-SA 4.0
2022-10-11T09:50:36.113Z
2022-10-19T12:34:52.457Z
2022-10-19T12:34:52.457Z
Michael Folkson
<p>LND users are <a href="https://twitter.com/roasbeef/status/1579274303006474242?s=20&amp;t=GobPLhhODesPil8VoT5t6A" rel="nofollow noreferrer">being asked</a> as of 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?</p>

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

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

LND users are [being asked](https://twitter.com/roasbeef/status/1579274303006474242?s=20&t=GobPLhhODesPil8VoT5t6A) as of 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?

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


---

## 1 answers

### Answer by username_0 on 2022-10-11. Score: 6 | Accepted answer

There was a bug in LND and btcd which was exposed by a perfectly valid 998-of-999 Taproot multisig [transaction](https://twitter.com/brqgoo/status/1579216353780957185?s=20&t=0KZqWYXHZWnSYSFZSsodkA) broadcast by Burak on October 9th 2022. This transaction met the Taproot consensus rules activated on the network in November 2021, was included in a block by a miner and verified by all Bitcoin Core full nodes (and as far as I know alternative implementations other than btcd).

(The transaction was analyzed [here](https://gist.github.com/AdamISZ/9b2395ddcb43890d9611df99287cfe6b) by AdamISZ.)

The Taproot consensus rule upgrade included in [BIP342](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#resource-limits):

> Script size limit: The maximum script size of 10000 bytes does not apply. Their size is only implicitly bounded by the block weight limit.

btcd full nodes rejected the transaction and the block the transaction was included in and its blockchain stalled. The btcd wire parsing library was still enforcing the maximum script size limit from SegWit version 0 for SegWit version 1 transactions.

This impacted all LND nodes (both those backed by a Bitcoin Core full node and those backed by a btcd full node) because the btcd wire parsing library that deserializes raw blocks is a LND dependency.

As Olaoluwa Osuntokun (LND, btcd maintainer) stated on Twitter:

> The issue was in btcd's wire parsing library that deserializes raw blocks, the initial implementation of segwit v0 included a consensus level check for witness size limits but *also* hoisted this check up to the wire parsing layer
>
> With segwit v1, this prior limit of the max accepted witness size was removed, in place of things like the sigop cost abstraction, effectively leaving the limit to the max block weight/size
>
> btcd's initial segwit v1 implementation correctly updated the consensus logic, but failed to also update the defense-in-depth check in the wire parsing layer (when parsing off the wire you want *some* sort of upper limit)

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](https://github.com/lightningnetwork/lnd/releases). 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](https://github.com/btcsuite/btcd/pull/1896). 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.

There was [further discussion](https://github.com/lightningnetwork/lnd/issues/7002) on why the Taproot (BIP341) static [test vectors](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#Test_vectors) didn't catch the bug in the LND repo. Olaoluwa Osuntokun again:

> btcd is/was using this test vectors. The issue here is that the code the parsed the witnesses for these test vectors isn't the same code that's used to read blocks off the wire. When a new block comes in, we fetch the raw block then attempt to decode it, which triggered this issue.

This bug was also covered in [Bitcoin Optech](https://bitcoinops.org/en/newsletters/2022/10/19/#block-parsing-bug-affecting-btcd-and-lnd).

> **Comments:**
> **username_1**: the root cause of the bug was that btcd still enforced pre-taproot script size limits. The bug was exposed by Burak's transaction, not caused by it  
> **username_0**: @username_1: Indeed, will improve the wording. Thanks  

---

