|
| 1 | +--- |
| 2 | +title: 'Bitcoin Optech Newsletter #225' |
| 3 | +permalink: /en/newsletters/2022/11/09/ |
| 4 | +name: 2022-11-09-newsletter |
| 5 | +slug: 2022-11-09-newsletter |
| 6 | +type: newsletter |
| 7 | +layout: newsletter |
| 8 | +lang: en |
| 9 | +--- |
| 10 | +This week's newsletter summarizes continued discussion about a configuration option for enabling |
| 11 | +full-RBF in Bitcoin Core and describes a bug affecting BTCD, LND, and |
| 12 | +other software. Also included are our regular sections with the summary |
| 13 | +of a Bitcoin Core PR Review Club meeting, descriptions of new releases |
| 14 | +and release candidates, and overviews of notable changes to popular |
| 15 | +Bitcoin infrastructure software. |
| 16 | + |
| 17 | +## News |
| 18 | + |
| 19 | +- **Continued discussion about enabling full-RBF:** as mentioned in |
| 20 | + newsletters for the past several weeks---users, service providers, and |
| 21 | + Bitcoin Core developers have been evaluating the inclusion of the |
| 22 | + `mempoolfullrbf` configuration option into Bitcoin Core's development |
| 23 | + branch and current release candidates for version 24.0. Those |
| 24 | + previous newsletters have summarized many previous |
| 25 | + arguments for and against this [full RBF][topic rbf] option |
| 26 | + ([1][news222 rbf], [2][news223 rbf], [3][news224 rbf]). This week, |
| 27 | + Suhas Daftuar [posted][daftuar rbf] to the Bitcoin-Dev mailing list to |
| 28 | + "argue that we should continue to maintain a relay policy where |
| 29 | + replacements are rejected for transactions that don't opt-in to RBF |
| 30 | + (as described in BIP 125), and moreover, that we should remove the |
| 31 | + `-mempoolfullrbf` flag from Bitcoin Core's latest release candidate |
| 32 | + and not plan to release software with that flag, unless (or until) |
| 33 | + circumstances change on the network." He notes: |
| 34 | + |
| 35 | + - *Opt-in RBF already available:* anyone who wants the benefits of |
| 36 | + RBF should be able to opt-in to it using the mechanism described in |
| 37 | + [BIP125][]. Users would only be served by full RBF if there was |
| 38 | + some reason they couldn't use opt-in RBF. |
| 39 | + |
| 40 | + - *Full RBF doesn't fix anything that isn't broken in other ways:* |
| 41 | + a possible case where some users of a multiparty protocol could |
| 42 | + deny other users the ability to use opt-in RBF was previously |
| 43 | + [identified][riard funny games], but Daftuar notes that protocol |
| 44 | + is vulnerable to other cheap or free attacks which full RBF would |
| 45 | + not solve. |
| 46 | + |
| 47 | + - *Full RBF takes away options:* "absent any other examples [of |
| 48 | + problems fixed by fullrbf], it does not seem to me that fullrbf |
| 49 | + solves any problems for RBF users, who are already free to choose |
| 50 | + to subject their transactions to BIP 125's RBF policy. From this |
| 51 | + perspective, "enabling fullrbf" is really just taking away user |
| 52 | + choice to opt a transaction into a non-replacement policy regime." |
| 53 | + |
| 54 | + - *Offering non-replacement doesn't introduce any issues for full nodes:* |
| 55 | + indeed, it simplifies the handling of long chains of transactions. |
| 56 | + |
| 57 | + - *Determining incentive compatibility isn't always straightforward:* |
| 58 | + Daftuar uses the proposal for v3 transaction relay (see |
| 59 | + [Newsletter #220][news220 v3tx]) as an example: |
| 60 | + |
| 61 | + > Suppose in a few years someone proposes that we add a |
| 62 | + > "-disable_v3_transaction_enforcement" flag to our software, to |
| 63 | + > let users decide to turn off those policy restrictions and |
| 64 | + > treat v3 transactions the same as v2, for all the same reasons |
| 65 | + > that could be argued today with fullrbf [...] |
| 66 | + > |
| 67 | + > [That] would be subversive to making the lightning use case for |
| 68 | + > v3 transactions work [...] we should not enable users to |
| 69 | + > disable this policy, because as long as that policy is just |
| 70 | + > optional and working for those who want it, it shouldn't harm |
| 71 | + > anyone that we offer a tighter set of rules for a particular |
| 72 | + > use case. Adding a way to bypass those rules is just trying to |
| 73 | + > break someone else's use case, not trying to add a new one. We |
| 74 | + > should not wield "incentive compatibility" as a bludgeon for |
| 75 | + > breaking things that appear to be working and not causing |
| 76 | + > others harm. |
| 77 | + > |
| 78 | + > I think this is exactly what is happening with fullrbf. |
| 79 | +
|
| 80 | + Daftuar ends his email with three questions for those who still want |
| 81 | + the `mempoolfullrbf` option to be included in Bitcoin Core: |
| 82 | + |
| 83 | + 1. "Does fullrbf offer any benefits other than breaking zeroconf |
| 84 | + business practices? If so, what are they?" |
| 85 | + |
| 86 | + 2. "Is it reasonable to enforce BIP 125's rbf rules on all |
| 87 | + transactions, if those rules themselves are not always incentive |
| 88 | + compatible?" |
| 89 | + |
| 90 | + 3. "If someone were to propose a command line option that breaks v3 |
| 91 | + transaction relay in the future, is there a logical basis for |
| 92 | + opposing that which is consistent with moving towards fullrbf |
| 93 | + now?" |
| 94 | + |
| 95 | + As of this writing, no one has answered Daftuar's questions on the |
| 96 | + mailing list, although two answers to the set of questions were |
| 97 | + posted to a Bitcoin Core [PR][bitcoin core #26438] that Daftuar |
| 98 | + opened to propose removing the `mempoolfullrbf` configuration |
| 99 | + option. Daftuar later [closed][26438 close] the PR. |
| 100 | + |
| 101 | + It wasn't clear at the time of writing whether anyone would comment |
| 102 | + further on the topic. |
| 103 | + |
| 104 | +- **Block parsing bug affecting multiple software:** as reported in |
| 105 | + [Newsletter #222][news222 bug], it appeared that a serious bug |
| 106 | + affecting the BTCD full node and LND LN node was accidentally |
| 107 | + triggered, putting users of the software at risk. Updated software |
| 108 | + was quickly released. Shortly after that bug was triggered, Anthony |
| 109 | + Towns [discovered][towns find] a second related bug that could only be |
| 110 | + triggered by miners. Towns reported the bug to BTCD and LND lead |
| 111 | + maintainer Olaoluwa Osuntokun, who prepared a patch to include in the |
| 112 | + next general update of the software. Including the security fix |
| 113 | + alongside other changes could hide that a vulnerability was being |
| 114 | + fixed and reduce the chance of it being exploited. Both Towns and |
| 115 | + Osuntokun responsibly kept the vulnerability private until its fix |
| 116 | + could be deployed. |
| 117 | + |
| 118 | + Unfortunately, the second related bug was independently rediscovered by |
| 119 | + someone who found a miner to trigger it. This new bug |
| 120 | + affected BTCD and LND again, but it also affected at least [two |
| 121 | + other][liquid and rust bitcoin vulns] significant projects or |
| 122 | + services. All users of affected systems should upgrade immediately. |
| 123 | + We repeat our advice from three weeks ago for anyone using any |
| 124 | + Bitcoin software to sign up for security announcements from that |
| 125 | + software’s development team. |
| 126 | + |
| 127 | + With the release of this newsletter, Optech has also added a special |
| 128 | + topic page where we list the names of [the amazing people who |
| 129 | + responsibly disclosed a vulnerability][topic responsible |
| 130 | + disclosures] that we've summarized in an Optech newsletter. |
| 131 | + There are likely several other disclosures not listed because they |
| 132 | + haven't been made public yet. |
| 133 | + We of course also thank all the reviewers of proposals and |
| 134 | + pull requests whose diligent effort prevented innumerable |
| 135 | + security bugs from making it into released software. |
| 136 | + |
| 137 | +## Bitcoin Core PR Review Club |
| 138 | + |
| 139 | +*In this monthly section, we summarize a recent [Bitcoin Core PR Review Club][] |
| 140 | +meeting, highlighting some of the important questions and answers. Click on a |
| 141 | +question below to see a summary of the answer from the meeting.* |
| 142 | + |
| 143 | +FIXME:LarryRuane |
| 144 | + |
| 145 | +{% include functions/details-list.md |
| 146 | + q0="FIXME" |
| 147 | + a0="FIXME" |
| 148 | + a0link="https://bitcoincore.reviews/26114#l-27FIXME" |
| 149 | +%} |
| 150 | + |
| 151 | +## Releases and release candidates |
| 152 | + |
| 153 | +*New releases and release candidates for popular Bitcoin infrastructure |
| 154 | +projects. Please consider upgrading to new releases or helping to test |
| 155 | +release candidates.* |
| 156 | + |
| 157 | +- [Rust Bitcoin 0.28.2][] is a minor release containing a fixes for bugs |
| 158 | + that could "cause some specific transactions and/or blocks to fail to |
| 159 | + deserialize. No known such transactions exist on any public |
| 160 | + blockchain." |
| 161 | + |
| 162 | +- [Bitcoin Core 24.0 RC3][] is a release candidate for the |
| 163 | + next version of the network's most widely used full node |
| 164 | + implementation. A [guide to testing][bcc testing] is available. |
| 165 | + |
| 166 | + **Warning:** this release candidate includes the `mempoolfullrbf` |
| 167 | + configuration option which several protocol and application developers |
| 168 | + believe could lead to problems for merchant services as described in |
| 169 | + this newsletter and previous newsletters [#222][news222 rbf] and |
| 170 | + [#223][news223 rbf]. It could also cause problems for transaction |
| 171 | + relay as described in [Newsletter #224][news224 rbf]. Optech |
| 172 | + encourages any services that might be affected to evaluate the RC and |
| 173 | + participate in the public discussion. |
| 174 | + |
| 175 | +## Notable code and documentation changes |
| 176 | + |
| 177 | +*Notable changes this week in [Bitcoin Core][bitcoin core repo], [Core |
| 178 | +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], |
| 179 | +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet |
| 180 | +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay |
| 181 | +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement |
| 182 | +Proposals (BIPs)][bips repo], and [Lightning BOLTs][bolts repo].* |
| 183 | + |
| 184 | +- [Bitcoin Core #26419][] log: mempool: log removal reason in validation interface FIXME:adamjonas |
| 185 | + |
| 186 | +- [Eclair #2404][] adds support for Short Channel IDentifier (SCID) |
| 187 | + aliases and [zero-conf channels][topic zero-conf channels] |
| 188 | + even for channel state commitments that don't use [anchor |
| 189 | + outputs][topic anchor outputs]. |
| 190 | + |
| 191 | +- [Eclair #2468][] implements [BOLTs #1032][], allowing the ultimate receiver of a payment ([HTLC][topic |
| 192 | + HTLC]) to accept a greater amount than they requested and with a |
| 193 | + longer time before it expires than they requested. Previously, |
| 194 | + Eclair-based receivers adhered to [BOLT4][]'s requirement that the |
| 195 | + amount and expiry delta equal exactly the amount they requested, but |
| 196 | + that exactitude meant a forwarding node could probe the next hop to |
| 197 | + see if it was the final receiver by changing either value by the |
| 198 | + slightest bit. |
| 199 | + |
| 200 | +- [Eclair #2469][] extends the amount of time it asks the last |
| 201 | + forwarding node to give the next hop to settle a payment. The last |
| 202 | + forwarding node shouldn't know it's the last forwarding node---it |
| 203 | + shouldn't know that the next hop is the receiver of the payment. The |
| 204 | + extra settlement time implies that the next hop may be a routing node |
| 205 | + rather than the receiver. The PR description for this feature states |
| 206 | + that Core Lightning and LDK already implement this behavior. See also |
| 207 | + the description for Eclair #2468 above. |
| 208 | + |
| 209 | +- [Eclair #2362][] adds support for the `dont_forward` flag for channel |
| 210 | + updates from [BOLTs #999][]. Channel updates change the parameters of |
| 211 | + a channel and are often gossiped to inform other nodes on the network |
| 212 | + about how to use the channel, but when a channel update contains this |
| 213 | + flag, it should not be forwarded to other nodes. |
| 214 | + |
| 215 | +- [Eclair #2441][] allows Eclair to begin receiving onion-wrapped error |
| 216 | + messages of any size. [BOLT2][] currently recommends 256 byte errors, |
| 217 | + but doesn't forbid longer error messages and [BOLTs #1021][] is open to |
| 218 | + encourage use of 1024-byte error messages encoded using LN's modern |
| 219 | + Type-Length-Value (TLV) semantics. |
| 220 | + |
| 221 | +- [LND #7100][] updates LND to use the latest version of BTCD (as a |
| 222 | + library), fixing the block parsing bug described in the *news* section |
| 223 | + above. |
| 224 | + |
| 225 | +- [LDK #1761][] adds a `PaymentID` parameter to methods for sending |
| 226 | + payments which callers can use to prevent sending multiple identical |
| 227 | + payments. Additionally, LDK may now continue trying to resend a |
| 228 | + payment indefinitely, rather than the previous behavior of ceasing |
| 229 | + retries after a few blocks of repeated failures; the `abandon_payment` |
| 230 | + method may be used to prevent further retrying. |
| 231 | + |
| 232 | +- [LDK #1743][] provides a new `ChannelReady` event when a channel |
| 233 | + becomes ready to use. Notably, the event may be issued after a |
| 234 | + channel has received a suitable number of confirmations, or it may be |
| 235 | + issued immediately in the case of a [zero-conf channel][topic zero-conf channels]. |
| 236 | + |
| 237 | +- [BTCPay Server #4157][] adds opt-in support for a new version of the |
| 238 | + checkout interface. See the PR for screenshots and video previews. |
| 239 | + |
| 240 | +- [BOLTs #1032][] allows the ultimate receiver of a payment |
| 241 | + ([HTLC][topic HTLC]) to accept a greater amount than they requested |
| 242 | + and with a longer time before it expires than they requested. This |
| 243 | + makes it more difficult for a forwarding node to determine that the |
| 244 | + next hop is the receiver by slightly tweaking a payment's parameters. |
| 245 | + See the description of Eclair #2468 above for more information. |
| 246 | + |
| 247 | +{% include references.md %} |
| 248 | +{% include linkers/issues.md v=2 issues="26438,26419,5674,2404,2468,2469,2362,2441,7100,1761,1743,4157,1032,1021,999,26398,11423" %} |
| 249 | +[bitcoin core 24.0 rc3]: https://bitcoincore.org/bin/bitcoin-core-24.0/ |
| 250 | +[rust bitcoin 0.28.2]: https://github.com/rust-bitcoin/rust-bitcoin/releases/tag/0.28.2 |
| 251 | +[bcc testing]: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Candidate-Testing-Guide |
| 252 | +[news222 rbf]: /en/newsletters/2022/10/19/#transaction-replacement-option |
| 253 | +[news223 rbf]: /en/newsletters/2022/10/26/#continued-discussion-about-full-rbf |
| 254 | +[news224 rbf]: /en/newsletters/2022/11/02/#mempool-consistency |
| 255 | +[daftuar rbf]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html |
| 256 | +[riard funny games]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html |
| 257 | +[news220 v3tx]: /en/newsletters/2022/10/05/#proposed-new-transaction-relay-policies-designed-for-ln-penalty |
| 258 | +[news222 bug]: /en/newsletters/2022/10/19/#block-parsing-bug-affecting-btcd-and-lnd |
| 259 | +[liquid and rust bitcoin vulns]: https://twitter.com/Liquid_BTC/status/1587499305664913413 |
| 260 | +[towns find]: https://twitter.com/roasbeef/status/1587481219981508608 |
| 261 | +[26438 close]: https://github.com/bitcoin/bitcoin/pull/26438#issuecomment-1307715677 |
0 commit comments