|
| 1 | +--- |
| 2 | +title: 'Bitcoin Optech Newsletter #251' |
| 3 | +permalink: /en/newsletters/2023/05/17/ |
| 4 | +name: 2023-05-17-newsletter |
| 5 | +slug: 2023-05-17-newsletter |
| 6 | +type: newsletter |
| 7 | +layout: newsletter |
| 8 | +lang: en |
| 9 | +--- |
| 10 | +This week's newsletter describes a proposal to begin testing HTLC |
| 11 | +endorsement, relays a request for feedback about proposed specifications |
| 12 | +for Lightning Service Providers (LSPs), discusses challenges with |
| 13 | +opening zero-conf channels when using dual funding, looks at a |
| 14 | +suggestion for advanced applications of payjoin transactions, and links |
| 15 | +to summaries of a recent in-person meeting of Bitcoin Core developers. |
| 16 | +Also included in this week's newsletter is the first part of a new |
| 17 | +series about policies for transaction relay and mempool inclusion, plus |
| 18 | +our regular sections announcing new releases and release candidates (including |
| 19 | +a security release of libsecp256k1) and |
| 20 | +describing notable changes to popular Bitcoin infrastructure software. |
| 21 | + |
| 22 | +## News |
| 23 | + |
| 24 | +- **Testing HTLC endorsement:** several weeks ago, Carla Kirk-Cohen and |
| 25 | + Clara Shikhelman [posted][kcs endorsement] to the Lightning-Dev mailing list about |
| 26 | + the next steps they and others planned to take to test the idea of |
| 27 | + [HTLC][topic htlc] endorsement (see [Newsletter #239][news239 |
| 28 | + endorsement]) as part of a mitigation for [channel jamming |
| 29 | + attacks][topic channel jamming attacks]. Most notably, they provided a |
| 30 | + short [proposed specification][bolts #1071] that could be deployed |
| 31 | + using an experimental flag, preventing deployments of it from having any effect on |
| 32 | + interactions with non-participating nodes. |
| 33 | + |
| 34 | + Once deployed by experimenters, it should become easier to answer |
| 35 | + one of the [constructive criticisms][decker endorsement] of this idea, which is how |
| 36 | + many forwarded payments would actually receive a boost from the |
| 37 | + scheme. If the core users of LN are |
| 38 | + frequently sending payments to each other over many of the same |
| 39 | + routes, and if the reputation system works as planned, then that |
| 40 | + core network will be more likely to keep functioning during a |
| 41 | + channel jamming attack. But if most spenders only send payments |
| 42 | + rarely (or only send their most critical types of payments rarely, |
| 43 | + such as high-value payments), then they won't have enough |
| 44 | + interactions to build a reputation, or the reputation data will lag |
| 45 | + far behind the current state of the network (making it less useful |
| 46 | + or even allowing reputation to be abused). |
| 47 | + |
| 48 | +- **Request for feedback on proposed specifications for LSPs:** Severin |
| 49 | + Bühler [posted][buhler lsp] to the Lightning-Dev mailing list a request for |
| 50 | + feedback on two specifications for interoperability between Lightning |
| 51 | + Service Providers (LSPs) and their clients (usually non-forwarding LN |
| 52 | + nodes). The first specification describes an API for allowing a |
| 53 | + client to purchase a channel from an LSP. The second describes an API |
| 54 | + for setting up and managing Just-In-Time (JIT) channels, which are |
| 55 | + channels that start their lives as virtual payment channels; when the |
| 56 | + first payment to the virtual channel is received, the LSP broadcasts a |
| 57 | + transaction that will anchor the channel onchain when it is confirmed |
| 58 | + (making it into a regular channel). |
| 59 | + |
| 60 | + In a [reply][zmnscpxj lsp], developer ZmnSCPxj wrote in favor of open specifications |
| 61 | + for LSPs. He noted that they make it easy for a client to connect |
| 62 | + to multiple LSPs, which will prevent vendor lock-in and improve |
| 63 | + privacy. |
| 64 | + |
| 65 | +- **Challenges with zero-conf channels when dual funding:** Bastien |
| 66 | + Teinturier [posted][teinturier 0conf] to the Lightning-Dev mailing list about the |
| 67 | + challenges of allowing [zero-conf channels][topic zero-conf channels] when using the |
| 68 | + [dual-funding protocol][topic dual funding]. Zero-conf channels can be used even before the |
| 69 | + channel open transaction is confirmed; this is trustless in some |
| 70 | + cases. Dual-funded channels are channels that were created using the |
| 71 | + dual-funding protocol, which may include channels where the open |
| 72 | + transaction contains inputs from both parties in the channel. |
| 73 | + |
| 74 | + Zero-conf is only trustless when one party controls all of the |
| 75 | + inputs to the open transaction. For example, Alice creates the |
| 76 | + open transaction, gives Bob some funds in the channel, and Bob tries |
| 77 | + spending those funds through Alice to Carol. Alice can safely forward |
| 78 | + the payment to Carol because Alice knows she's in control of the |
| 79 | + open transaction eventually becoming confirmed. But if Bob also has |
| 80 | + an input in the open transaction, he can get a conflicting |
| 81 | + transaction confirmed that will prevent the open transaction from |
| 82 | + confirming---preventing Alice from being compensated for any money |
| 83 | + she forwarded to Carol. |
| 84 | + |
| 85 | + Several ideas for allowing zero-conf channel opens with dual funding |
| 86 | + were discussed, although none seemed satisfying to participants as |
| 87 | + of this writing. |
| 88 | + |
| 89 | +- **Advanced payjoin applications:** Dan Gould [posted][gould payjoin] to the |
| 90 | + Bitcoin-Dev mailing list several suggestions for using the |
| 91 | + [payjoin][topic payjoin] protocol to do more than just send or receive |
| 92 | + a simple payment. Two of the suggestions we found most interesting |
| 93 | + were versions of [transaction cut-through][], an old idea for |
| 94 | + improving privacy, improving scalability, and reducing fee costs: |
| 95 | + |
| 96 | + - *Payment forwarding:* rather than Alice paying Bob, Alice instead |
| 97 | + pays Bob's vendor (Carol), reducing a debt he owes her (or |
| 98 | + pre-paying for an expected future bill). |
| 99 | + |
| 100 | + - *Batched payment forwarding:* rather than Alice paying Bob, Alice |
| 101 | + instead pays several people Bob owes money (or wants to establish |
| 102 | + a credit with). Gould's example considers an exchange that has a |
| 103 | + steady stream of deposits and withdrawals; payjoin allows withdrawals |
| 104 | + to be paid for by new deposits when possible. |
| 105 | + |
| 106 | + Both of these techniques allow reducing what would be at least two |
| 107 | + transactions into a single transaction, saving a considerable amount |
| 108 | + of block space. When [batching][topic payment batching] is used, |
| 109 | + the space savings may be even larger. Even better from the |
| 110 | + perspective of the original receiver (e.g. Bob), |
| 111 | + the original spender (e.g. Alice) may pay all or some of the |
| 112 | + fees. Beyond the space and fee savings, removing transactions from |
| 113 | + the block chain and combining operations like receiving and spending |
| 114 | + makes it significantly more difficult for block chain surveillance |
| 115 | + organizations to reliably trace the flow of funds. |
| 116 | + |
| 117 | + As of this writing, the post had not received any discussion on the |
| 118 | + mailing list. |
| 119 | + |
| 120 | +- **Summaries of Bitcoin Core developers in-person meeting:** several |
| 121 | + developers working on Bitcoin Core recently met to discuss aspects of |
| 122 | + the project. Notes from several discussions during that meeting have |
| 123 | + been published. Topics discussed included [fuzz testing][], |
| 124 | + [assumeUTXO][], [ASMap][], [silent payments][], [libbitcoinkernel][], |
| 125 | + [refactoring (or not)][], and [package relay][]. Also discussed were |
| 126 | + two other topics we think deserve special attention: |
| 127 | + |
| 128 | + - [Mempool clustering][] summarizes a suggestion for a significant |
| 129 | + redesign of how transactions and their metadata are stored in |
| 130 | + Bitcoin Core's mempool. The notes describe a number of problems |
| 131 | + with the current design, provide an overview of the new design, |
| 132 | + and suggest some of the challenges and tradeoffs involved. A |
| 133 | + [description][bitcoin core #27677] of the design and a copy of the |
| 134 | + [slides][mempool slides] from the presentation were later published. |
| 135 | + |
| 136 | + - [Project meta discussion][] summarizes a varied discussion about |
| 137 | + the project's goals and how to achieve them despite many |
| 138 | + challenges, both internal and external. Some of the discussion |
| 139 | + has already led to experimental changes in the project's |
| 140 | + management, such as a more project-focused approach for the next |
| 141 | + major release after version 25. |
| 142 | + |
| 143 | +## Waiting for confirmation #1: why do we have a mempool? |
| 144 | + |
| 145 | +_The first segment in a limited weekly series about transaction relay, |
| 146 | +mempool inclusion, and mining transaction selection---including why |
| 147 | +Bitcoin Core has a more restrictive policy than allowed by consensus and |
| 148 | +how wallets can use that policy most effectively._ |
| 149 | + |
| 150 | +{% include specials/policy/en/01-why-mempool.md %} |
| 151 | + |
| 152 | +## Releases and release candidates |
| 153 | + |
| 154 | +*New releases and release candidates for popular Bitcoin infrastructure |
| 155 | +projects. Please consider upgrading to new releases or helping to test |
| 156 | +release candidates.* |
| 157 | + |
| 158 | +- [Libsecp256k1 0.3.2][] is a security release for applications that use |
| 159 | + libsecp for [ECDH][] and that may be compiled with GCC version 13 or |
| 160 | + higher. As [described by the authors][secp ml], new versions of GCC |
| 161 | + attempt to optimize libsecp code that was designed to run in a fixed |
| 162 | + amount of time, making it possible to execute a [side-channel |
| 163 | + attack][topic side channels] under certain circumstances. It's worth |
| 164 | + noting that Bitcoin Core does not use ECDH and is not affected. There |
| 165 | + is ongoing work to try to detect when future changes to compilers |
| 166 | + might cause similar problems, allowing changes to be made in advance. |
| 167 | + |
| 168 | +- [Core Lightning 23.05rc2][] is a release candidate for the next |
| 169 | + version of this LN implementation. |
| 170 | + |
| 171 | +- [Bitcoin Core 23.2rc1][] is a release candidate for a maintenance |
| 172 | + release of the previous major version of Bitcoin Core. |
| 173 | + |
| 174 | +- [Bitcoin Core 24.1rc3][] is a release candidate for a maintenance |
| 175 | + release of the current version of Bitcoin Core. |
| 176 | + |
| 177 | +- [Bitcoin Core 25.0rc2][] is a release candidate for the next major |
| 178 | + version of Bitcoin Core. |
| 179 | + |
| 180 | +## Notable code and documentation changes |
| 181 | + |
| 182 | +*Notable changes this week in [Bitcoin Core][bitcoin core repo], [Core |
| 183 | +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], |
| 184 | +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet |
| 185 | +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay |
| 186 | +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement |
| 187 | +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], and |
| 188 | +[Bitcoin Inquisition][bitcoin inquisition repo].* |
| 189 | + |
| 190 | +- [Bitcoin Core #26076][] Switch hardened derivation marker to h FIXME:Xekyo |
| 191 | + |
| 192 | +- [Bitcoin Core #27608][] will continue trying to download a block from |
| 193 | + a peer even if another peer provided the block. Bitcoin Core will |
| 194 | + continue trying to download the block from peers that claim to have it |
| 195 | + until one of the received blocks has been written to disk. |
| 196 | + |
| 197 | +- [LDK #2286][] allows creating and signing [PSBTs][topic psbt] for |
| 198 | + outputs controlled by the local wallet. |
| 199 | + |
| 200 | +- [LDK #1794][] begins adding support for [dual funding][topic dual |
| 201 | + funding], starting with methods needed for the interactive funding |
| 202 | + protocol that is used for dual funding. |
| 203 | + |
| 204 | +- [Rust Bitcoin #1844][] makes the schema in a [BIP21][] URI lowercase, |
| 205 | + i.e. `bitcoin:`. Although the specification for URI schema (RFC3986) |
| 206 | + says the schema is case insensitive, testing shows that some platforms |
| 207 | + are not opening the application assigned to handle `bitcoin:` URIs |
| 208 | + when an uppercase `BITCOIN:` is passed. It would be preferable if |
| 209 | + uppercase was handled correctly, as it allows the creation of more efficient |
| 210 | + QR codes (see [Newsletter #46][news46 qr]). |
| 211 | + |
| 212 | +- [Rust Bitcoin #1837][] adds a function for generating a new private |
| 213 | + key, simplifying what previously required more code to accomplish. |
| 214 | + |
| 215 | +- [BOLTs #1075][] updates the specification so that nodes should no |
| 216 | + longer disconnect from a peer after receiving a warning message from |
| 217 | + it. |
| 218 | + |
| 219 | +{% include references.md %} |
| 220 | +{% include linkers/issues.md v=2 issues="26076,27608,2286,1794,1844,1837,1075,1071,27677" %} |
| 221 | +[Core Lightning 23.05rc2]: https://github.com/ElementsProject/lightning/releases/tag/v23.05rc2 |
| 222 | +[bitcoin core 23.2rc1]: https://bitcoincore.org/bin/bitcoin-core-23.2/ |
| 223 | +[bitcoin core 24.1rc3]: https://bitcoincore.org/bin/bitcoin-core-24.1/ |
| 224 | +[bitcoin core 25.0rc2]: https://bitcoincore.org/bin/bitcoin-core-25.0/ |
| 225 | +[news239 endorsement]: /en/newsletters/2023/02/22/#feedback-requested-on-ln-good-neighbor-scoring |
| 226 | +[fuzz testing]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-27-fuzzing/ |
| 227 | +[assumeutxo]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-27-assumeutxo/ |
| 228 | +[asmap]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-27-asmap/ |
| 229 | +[silent payments]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-26-silent-payments/ |
| 230 | +[libbitcoinkernel]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-26-libbitcoin-kernel/ |
| 231 | +[refactoring (or not)]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-25-refactors/ |
| 232 | +[package relay]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-25-package-relay-primer/ |
| 233 | +[mempool clustering]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-25-mempool-clustering/ |
| 234 | +[project meta discussion]: https://btctranscripts.com/bitcoin-core-dev-tech/2023-04-26-meta-discussion/ |
| 235 | +[kcs endorsement]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003918.html |
| 236 | +[decker endorsement]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003944.html |
| 237 | +[buhler lsp]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003926.html |
| 238 | +[zmnscpxj lsp]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003930.html |
| 239 | +[teinturier 0conf]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003920.html |
| 240 | +[gould payjoin]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021653.html |
| 241 | +[transaction cut-through]: https://bitcointalk.org/index.php?topic=281848.0 |
| 242 | +[news46 qr]: /en/newsletters/2019/05/14/#bech32-sending-support |
| 243 | +[mempool slides]: https://github.com/bitcoin/bitcoin/files/11490409/Reinventing.the.Mempool.pdf |
| 244 | +[secp ml]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021683.html |
| 245 | +[libsecp256k1 0.3.2]: https://github.com/bitcoin-core/secp256k1/releases/tag/v0.3.2 |
| 246 | +[ecdh]: https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman |
0 commit comments