|
| 1 | +--- |
| 2 | +title: 'Bitcoin Optech Newsletter #332' |
| 3 | +permalink: /en/newsletters/2024/12/06/ |
| 4 | +name: 2024-12-06-newsletter |
| 5 | +slug: 2024-12-06-newsletter |
| 6 | +type: newsletter |
| 7 | +layout: newsletter |
| 8 | +lang: en |
| 9 | +--- |
| 10 | +This week's newsletter announces the disclosure of a transaction |
| 11 | +censorship vulnerability and summarizes discussion about the consensus |
| 12 | +cleanup soft fork proposal. Also included are our regular sections |
| 13 | +announcing new releases and release candidates and describing notable |
| 14 | +changes to popular Bitcoin infrastructure software. |
| 15 | + |
| 16 | +## News |
| 17 | + |
| 18 | +- **Transaction censorship vulnerability:** Antoine Riard [posted][riard |
| 19 | + censor] to the Bitcoin-Dev mailing list about a method for preventing |
| 20 | + a node from broadcasting a transaction belonging to a connected |
| 21 | + wallet. If the connected wallet belongs to the user's LN node, the |
| 22 | + attack can be used to prevent the user from securing funds owed to |
| 23 | + them before a timeout expires and allows their counterparty to steal |
| 24 | + the funds. |
| 25 | + |
| 26 | + There are two versions of the attack, both of which take advantage of |
| 27 | + limits within Bitcoin Core related to the maximum number of |
| 28 | + unconfirmed transactions it will broadcast or accept within a certain |
| 29 | + period of time. These limits prevent it from placing an excessive |
| 30 | + burden on its peers or being denial-of-service attacked. |
| 31 | + |
| 32 | + The first version of the attack, called _high overflow_ by Riard, |
| 33 | + takes advantage of Bitcoin Core only broadcasting a maximum of 1,000 |
| 34 | + unconfirmed transaction announcements at a time to its peers. If more |
| 35 | + than 1,000 transactions are queued to be transmitted, the highest |
| 36 | + feerate transactions are announced first. After sending a batch of |
| 37 | + announcements, Bitcoin Core will wait to send more transactions until |
| 38 | + its recent average rate of announcements is seven transactions per |
| 39 | + second. |
| 40 | + |
| 41 | + If all 1,000 initial announcements pay a higher feerate than the |
| 42 | + transaction the victim wants to broadcast, and if an attacker |
| 43 | + continues to send the victim node at least seven transactions per |
| 44 | + second above that feerate, the attacker can prevent the broadcast |
| 45 | + indefinitely. Most attacks on LN will need to delay broadcast for |
| 46 | + between 32 blocks (Core Lightning defaults) and 140 blocks (Eclair |
| 47 | + defaults), which at 10 sats/vbyte would cost between 1.3 BTC ($130,000 |
| 48 | + USD) and 5.9 BTC ($590,000 USD), although Riard notes that a careful |
| 49 | + attacker who is well connected to other relay nodes (or directly to |
| 50 | + large miners) may be able to significantly reduce these costs. |
| 51 | + |
| 52 | + The second version of the attack, called _low overflow_ by Riard, |
| 53 | + takes advantage of Bitcoin Core refusing to allow its queue of |
| 54 | + unrequested transactions to grow beyond 5,000 per peer. The attacker |
| 55 | + sends the victim a huge number of transactions at a minimum feerate; |
| 56 | + the victim announces these to its honest peers and the peers queue the |
| 57 | + announcements; periodically, they attempt to drain the queue by |
| 58 | + requesting the transactions but a deficit builds until it reaches the |
| 59 | + 5,000 announcement limit. At that point, the peers ignore further |
| 60 | + announcements until the queue has partially drained. If the victim's |
| 61 | + honest transaction is announced during that time, the peers will |
| 62 | + ignore it. This attack can be significantly cheaper than the |
| 63 | + high-overflow variant because the attacker's junk transactions can |
| 64 | + pay the minimum transaction relay fee. However, the attack may be |
| 65 | + less reliable, in which case the attacker loses money spent on fees |
| 66 | + without gaining anything from the theft. |
| 67 | + |
| 68 | + At their simplest, the attacks do not appear to be concerning. Very |
| 69 | + few channels are likely to have pending payments exceeding the cost of |
| 70 | + the attack. Riard recommends that users of high-value LN channels |
| 71 | + operate additional full nodes, including those that do not accept |
| 72 | + inbound connections and which use _blocks only mode_ to ensure that |
| 73 | + they only relay unconfirmed transactions submitted by a local wallet. |
| 74 | + More sophisticated attacks that lower costs, or attacks that use the |
| 75 | + same set of junk transactions to attack multiple LN channels |
| 76 | + simultaneously, could affect even lower-value channels. Riard |
| 77 | + suggests several mitigations for LN implementations and leaves for |
| 78 | + later discussion possible changes to Bitcoin Core's P2P relay protocol |
| 79 | + that could address the issue. |
| 80 | + |
| 81 | + _Note to readers:_ we apologize if there are any errors in the above |
| 82 | + description; we only learned of the disclosure shortly before we |
| 83 | + went to publish this week's newsletter. |
| 84 | + |
| 85 | +- **Continued discussion about consensus cleanup soft fork proposal:** |
| 86 | + Antoine Poinsot [posted][poinsot time warp] to the existing Delving |
| 87 | + Bitcoin thread about the [consensus cleanup][topic consensus cleanup] |
| 88 | + soft fork proposal. In addition to the already proposed fix for the |
| 89 | + classic [time warp vulnerability][topic time warp], he proposed also |
| 90 | + including a fix for the recently discovered Zawy-Murch time warp (see |
| 91 | + [Newsletter #316][news316 time warp]). He favored a fix originally |
| 92 | + proposed by Mark "Murch" Erhardt: "require that the last block in a |
| 93 | + difficulty period _N_ has a higher timestamp than the first block in |
| 94 | + the same difficulty period _N_". |
| 95 | + |
| 96 | + Anthony Towns [favored][towns time warp] an alternative solution |
| 97 | + proposed by Zawy that would forbid any block from claiming it was |
| 98 | + produced more than two hours before any previous block. Zawy |
| 99 | + [noted][zawy time warp] that his every-block solution would increase the |
| 100 | + risk of miners losing money from running outdated software but it |
| 101 | + would also make timestamps more accurate for other uses, such as |
| 102 | + [timelocks][topic timelocks]. |
| 103 | + |
| 104 | + Separately, both on [Delving Bitcoin][poinsot duptx delv] and the |
| 105 | + [Bitcoin-Dev mailing list][poinsot duptx ml], Poinsot sought feedback |
| 106 | + about which proposed solution to use to prevent block 1,983,702 and |
| 107 | + some later blocks from [duplicating][topic duplicate transactions] a |
| 108 | + previous coinbase transaction (which could lead to loss of money and |
| 109 | + the creation of an attack vector). Four proposed solutions are |
| 110 | + presented, all of which would only directly affect miners---so |
| 111 | + [feedback from miners][mining-dev] would be especially appreciated. |
| 112 | + |
| 113 | +## Releases and release candidates |
| 114 | + |
| 115 | +_New releases and release candidates for popular Bitcoin infrastructure |
| 116 | +projects. Please consider upgrading to new releases or helping to test |
| 117 | +release candidates._ |
| 118 | + |
| 119 | +- [Eclair v0.11.0][] is the latest release of this popular LN node |
| 120 | + implementation. It "adds official support for BOLT12 [offers][topic |
| 121 | + offers] and makes progress on liquidity management features |
| 122 | + ([splicing][topic splicing], [liquidity ads][topic liquidity |
| 123 | + advertisements], and [on-the-fly funding][topic jit channels])." The |
| 124 | + release also stops accepting new non-[anchor channels][topic anchor |
| 125 | + outputs]. Also included are optimizations and bug fixes. |
| 126 | + |
| 127 | +- [LDK v0.0.125][] is the latest release of this library for building |
| 128 | + LN-enabled applications. It contains several bug fixes. |
| 129 | + |
| 130 | +- [Core Lightning 24.11rc3][] is a release candidate for the next major |
| 131 | + version of this popular LN implementation. |
| 132 | + |
| 133 | +- [LND 0.18.4-beta.rc1][] is a release candidate for a minor version of |
| 134 | + this popular LN implementation. |
| 135 | + |
| 136 | +- [Bitcoin Core 28.1RC1][] is a release candidate for a maintenance |
| 137 | + version of the predominant full node implementation. |
| 138 | + |
| 139 | +## Notable code and documentation changes |
| 140 | + |
| 141 | +_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core |
| 142 | +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], |
| 143 | +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet |
| 144 | +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay |
| 145 | +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement |
| 146 | +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], |
| 147 | +[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition |
| 148 | +repo], and [BINANAs][binana repo]._ |
| 149 | + |
| 150 | +- [Bitcoin Core #30708][] rpc: add getdescriptoractivity |
| 151 | + |
| 152 | +- [Core Lightning #7832][] anchors: create low priority anchor to spend commit tx within a week. |
| 153 | + |
| 154 | +- [LND #8270][] DynComms [1/n]: Implement Quiescence Protocol |
| 155 | + |
| 156 | +- [LND #8390][] Add Experimental Endorsement Signalling |
| 157 | + |
| 158 | +- [BIPs #1534][] Add BIP 349: OP_INTERNALKEY |
| 159 | + |
| 160 | +{% assign four_days_after_posting = page.date | date: "%s" | plus: 345600 | date: "%Y-%m-%d 15:30" %} |
| 161 | +{% include snippets/recap-ad.md when=four_days_after_posting %} |
| 162 | +{% include references.md %} |
| 163 | +{% include linkers/issues.md v=2 issues="30708,7832,8270,8390,1534" %} |
| 164 | +[core lightning 24.11rc3]: https://github.com/ElementsProject/lightning/releases/tag/v24.11rc3 |
| 165 | +[lnd 0.18.4-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.18.4-beta.rc1 |
| 166 | +[news316 time warp]: /en/newsletters/2024/08/16/#new-time-warp-vulnerability-in-testnet4 |
| 167 | +[poinsot time warp]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/53 |
| 168 | +[towns time warp]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/54 |
| 169 | +[zawy time warp]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/55 |
| 170 | +[poinsot duptx delv]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/51 |
| 171 | +[poinsot duptx ml]: https://groups.google.com/g/bitcoindev/c/KRwDa8aX3to |
| 172 | +[mining-dev]: https://groups.google.com/g/bitcoinminingdev/c/qyrPzU1WKSI |
| 173 | +[eclair v0.11.0]: https://github.com/ACINQ/eclair/releases/tag/v0.11.0 |
| 174 | +[ldk v0.0.125]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.125 |
| 175 | +[bitcoin core 28.1RC1]: https://bitcoincore.org/bin/bitcoin-core-28.1/ |
| 176 | +[riard censor]: https://groups.google.com/g/bitcoindev/c/GuS36ldye7s |
0 commit comments