Jekyll2022-12-17T00:11:45+00:00https://bitcoinops.org/Bitcoin OptechHelping Bitcoin-based businesses integrate scaling technology.Bitcoin OptechBitcoin Optech Newsletter #231: 2022 Year-in-Review Special2022-12-21T00:00:00+00:002022-12-21T00:00:00+00:00https://bitcoinops.org/en/newsletters/2022/12/2022-12-21-newsletter<p>This special edition of the Optech Newsletter summarizes notable developments in Bitcoin during all of 2022.
It’s the sequel to our summaries from <a href="/en/newsletters/2018/12/28/">2018</a>, <a href="/en/newsletters/2019/12/28/">2019</a>, <a href="/en/newsletters/2020/12/23/">2020</a>, and <a href="/en/newsletters/2021/12/22/">2021</a>.</p>
<h2 id="contents">Contents</h2>
<ul>
<li>January
<ul>
<li><a href="#stateless-invoices">Stateless invoices</a></li>
<li><a href="#defense-fund">Legal defense fund</a></li>
</ul>
</li>
<li>February
<ul>
<li><a href="#fee-sponsorship">Fee sponsorship</a></li>
<li><a href="#phantom-node-payments">Phantom node payments</a></li>
</ul>
</li>
<li>March
<ul>
<li><a href="#ln-pathfinding">LN pathfinding</a></li>
<li><a href="#zero-conf-channels">Zero-conf channels</a></li>
</ul>
</li>
<li>April
<ul>
<li><a href="#silent-payments">Silent payments</a></li>
<li><a href="#taro">Taro</a></li>
<li><a href="#quantum-safe-keys">Quantum-safe key exchange</a></li>
</ul>
</li>
<li>May
<ul>
<li><a href="#musig2">MuSig2</a></li>
<li><a href="#package-relay">Package relay</a></li>
<li><a href="#libbitcoinkernel">Bitcoin kernel library</a></li>
</ul>
</li>
<li>June
<ul>
<li><a href="#ln-meet">LN protocol developers meeting</a></li>
</ul>
</li>
<li>July
<ul>
<li><a href="#onion-message-limiting">Onion message rate limiting</a></li>
<li><a href="#miniscript-descriptors">Miniscript descriptors</a></li>
</ul>
</li>
<li>August
<ul>
<li><a href="#dual-funding">LN interactive and dual funding</a></li>
<li><a href="#jamming">Channel jamming attack mitigation</a></li>
<li><a href="#dlc-bls">BLS signatures for DLCs</a></li>
</ul>
</li>
<li>September
<ul>
<li><a href="#fee-ratecards">Fee ratecards</a></li>
</ul>
</li>
<li>October
<ul>
<li><a href="#v3-tx-relay">Version 3 transaction relay</a></li>
<li><a href="#async-payments">Async payments</a></li>
<li><a href="#parsing-bugs">Block parsing bugs</a></li>
<li><a href="#zk-rollups">ZK rollups</a></li>
<li><a href="#v2-transport">Encrypted version 2 transport protocol</a></li>
<li><a href="#core-meet">Meeting of Bitcoin protocol developers</a></li>
</ul>
</li>
<li>November
<ul>
<li><a href="#fat-errors">Fat error messages</a></li>
</ul>
</li>
<li>December
<ul>
<li><a href="#ln-mod">Modifying the LN protocol</a></li>
</ul>
</li>
<li>Featured summaries
<ul>
<li><a href="#rbf">Replace-By-Fee</a></li>
<li><a href="#releases">Major releases of popular infrastructure projects</a></li>
<li><a href="#optech">Bitcoin Optech</a></li>
<li><a href="#softforks">Soft fork proposals</a></li>
</ul>
</li>
</ul>
<h2 id="january">January</h2>
<p id="stateless-invoices">In January, LDK <a href="/en/newsletters/2022/01/05/#rust-lightning-1177">merged</a> an implementation of
<a href="/en/topics/stateless-invoices/">stateless invoices</a>, which allows it to
generate an infinite number of invoices without storing any data about
them unless payment is successful. Stateless invoices were previously
proposed in September 2021 and LDK’s implementation differs from the
suggested method, although it accomplishes the same goal and doesn’t
require any LN protocol changes. Later that month, an <a href="/en/newsletters/2022/01/12/#bolts-912">update</a> to the LN specification was merged to allow other types of
stateless invoices, with at least partial support for it being added to
<a href="/en/newsletters/2022/01/19/#eclair-2063">Eclair</a>, <a href="/en/newsletters/2022/04/13/#core-lightning-5086">Core Lightning</a>, and
<a href="/en/newsletters/2022/04/20/#lnd-5810">LND</a>.</p>
<p id="defense-fund">Also in January, a Bitcoin Legal Defense Fund was <a href="/en/newsletters/2022/01/19/#bitcoin-and-ln-legal-defense-fund">announced</a> by Jack Dorsey, Alex Morcos, and Martin White. It
provides “a nonprofit entity that aims to minimize legal headaches that
discourage software developers from actively developing Bitcoin and
related projects.”</p>
<h2 id="february">February</h2>
<p id="fee-sponsorship">A <a href="/en/newsletters/2022/01/12/#fee-accounts">discussion</a> in January about making it easier to
add fees to presigned transactions, lead to <a href="/en/newsletters/2022/02/23/#fee-bumping-and-transaction-fee-sponsorship">renewed discussion</a> in February about Jeremy
Rubin’s <a href="/en/topics/fee-sponsorship/">transaction fee sponsorship</a> idea from 2020.
Several challenges to its implementation were mentioned. Although the
immediate discussion didn’t make much progress, a technique that
accomplished similar goals—but which, unlike sponsorship, didn’t
require a soft fork—would be <a href="/en/newsletters/2022/12/21/#v3-tx-relay">proposed</a> in October.</p>
<p id="phantom-node-payments">LDK’s early support for <a href="/en/topics/stateless-invoices/">stateless invoices</a>
allowed it to add a new and <a href="/en/newsletters/2022/02/23/#ldk-1199">simple</a> method for load
balancing an LN node called <em>phantom node payments</em>.</p>
<p class="center"><img src="/img/posts/2022-02-phantom-node-payments.dot.png" alt="Illustration of phantom node payment path" /></p>
<h2 id="march">March</h2>
<p id="ln-pathfinding">The LN pathfinding algorithm first published in 2021 by René Pickhardt
and Stefan Richter received an <a href="/en/newsletters/2022/03/23/#payment-delivery-algorithm-update">update</a> in March with
Pickhardt noting an improvement that made it much more computationally
efficient.</p>
<p id="zero-conf-channels">A consistent method for allowing <a href="/en/topics/zero-conf-channels/">zero-conf channels</a> was <a href="/en/newsletters/2022/06/08/#bolts-910">specified</a> and began seeing
implementation support, starting with LDK’s <a href="/en/newsletters/2022/03/23/#ldk-1311">addition</a>
in March of support for the related Short Channel IDentifier (SCID)
<em>alias</em> field, followed by <a href="/en/newsletters/2022/06/22/#eclair-2224">Eclair</a>,
<a href="/en/newsletters/2022/07/13/#core-lightning-5275">Core Lightning</a>, and
<a href="/en/newsletters/2022/07/13/#lnd-5955">LND</a>.</p>
<p class="center"><img src="/img/posts/2021-07-zeroconf-channels.png" alt="Illustration of zero-conf channels" /></p>
<div class="callout" id="rbf">
<h3 id="summaryreplace-by-fee">2022 summary<br />Replace-By-Fee</h3>
<p>This year saw much discussion, and some significant actions, related to
<a href="/en/topics/replace-by-fee/">Replace By Fee</a> (RBF). Our January newsletter
<a href="/en/newsletters/2022/01/05/#brief-full-rbf-then-opt-in-rbf">summarized</a> a proposal by Jeremy Rubin to allow any
transaction to be replaced by a higher fee alternative for a brief while
after it was first seen by a node. After that time has passed, the
existing rules would apply—only allowing replacement of transactions
opting in to <a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki">BIP125</a>. This could allow merchants to accept
unconfirmed transactions like they do now after the replacement time
elapsed. More importantly, it may allow protocols that depend on
replaceability for security to not have to worry about non-opt-in
transactions as long as a protocol node or watchtower can reasonably
respond soon after first learning of a transaction.</p>
<p>At the end of January, Gloria Zhao started a fresh discussion about RBF
by <a href="/en/newsletters/2022/02/09/#discussion-about-rbf-policy">posting</a> background on the current RBF policy, with the
enumeration of several problems discovered with it over the years (such
as <a href="/en/topics/transaction-pinning/">pinning attacks</a>), an examination of how
the policy affects wallet user interfaces, and the description of
several possible improvements. In early March, Zhao followed up with
the <a href="/en/newsletters/2022/03/16/#ideas-for-improving-rbf-policy">summary</a> of two discussions about RBF between many
developers, one discussion in person and the other online.</p>
<p>Also in March, Larry Ruane raised <a href="/en/newsletters/2022/03/30/#transaction-witness-replacement">questions</a> related to
RBF about replacing transaction witnesses without changing other parts
of a transaction.</p>
<p>In June, Antoine Riard <a href="/en/newsletters/2022/06/22/#full-replace-by-fee">opened</a> a pull request to Bitcoin
Core to add a <code class="highlighter-rouge">mempoolfullrbf</code> configuration option to Bitcoin Core.
The option defaulted to Bitcoin Core’s previous behavior of only
allowing unconfirmed transactions to be replaced if they contained the
<a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki">BIP125</a> signal. Nodes which were configured with the option set to
it’s alternative value would accept transactions for relay and mining
even if they replaced transactions that did not contain the BIP125
opt-in signal. Riard also started a thread on the Bitcoin-Dev mailing
list to discuss the change. Almost all pull request comments were
positive and most mailing list discussion was about unrelated topics, so
it was unsurprising that the pull request was <a href="/en/newsletters/2022/07/13/#bitcoin-core-25353">merged</a>
about a month after it was opened.</p>
<p>In October, the Bitcoin Core project began distributing release
candidates for version 24.0, which would be the first to include the
<code class="highlighter-rouge">mempoolfullrbf</code> configuration option. Dario Sneidermanis saw the draft
release notes about the option and <a href="/en/newsletters/2022/10/19/#transaction-replacement-option">posted</a> to the
Bitcoin-Dev mailing list that too many users and miners enabling the
option would make unsignaled replacement reliable. More reliable
unsignaled replacement would also make it more reliable to steal from
services that accept unconfirmed transactions as final, requiring those
services to change their behavior. Discussion <a href="/en/newsletters/2022/10/26/#continued-discussion-about-full-rbf">continued</a>
the next week and the <a href="/en/newsletters/2022/11/02/#mempool-consistency">week after</a>. A month after
Sneidermanis raised the initial concern on the mailing list, Suhas
Daftuar <a href="/en/newsletters/2022/11/09/#continued-discussion-about-enabling-full-rbf">summarized</a> some of the arguments against the
option and opened a pull request to remove it from Bitcoin Core.</p>
<p>Many counterarguments in favor of keeping the <code class="highlighter-rouge">mempoolfullrbf</code> option
were also made. Those included several wallet developers noting that
they sometimes encounter users who want to make replacements even though
those users didn’t opt in to BIP125.</p>
<p>By the end of November, Daftuar closed his PR and the Bitcoin Core
project released version 24.0 with the <code class="highlighter-rouge">mempoolfullrbf</code> option. In
December, developer 0xB10C <a href="/en/newsletters/2022/12/14/#monitoring-of-full-rbf-replacements">released</a> a website for
monitoring transaction replacements which did not contain the BIP125
signal, indicating that any of those transactions which became confirmed
may have been processed by a miner using the <code class="highlighter-rouge">mempoolfullrbf</code> option to
enable full-RBF (or a similar feature in other software). At the end of
the year, full-RBF was still being discussed in other Bitcoin Core PRs
and on the mailing list.</p>
</div>
<h2 id="april">April</h2>
<p id="silent-payments">In April, Ruben Somsen <a href="/en/newsletters/2022/04/06/#delinked-reusable-addresses">proposed</a> the idea of <a href="/en/topics/silent-payments/">silent
payments</a>, which would allow someone to pay a
public identifier (“address”) without using that identifier onchain. This
would help prevent <a href="/en/topics/output-linking/">address reuse</a>. For example,
Alice would be able to post a public identifier on her website that Bob
can transform into a new unique Bitcoin address from which only Alice
will be able to spend. If Carol later goes to Alice’s website and
reuses Alice’s public identifier, she would derive a different address
to pay Alice, an address which neither Bob nor any other third party
could directly determine belonged to Alice. Later, developer W0ltx
would <a href="/en/newsletters/2022/06/01/#experimentation-with-silent-payments">implement</a> silent payments for Bitcoin Core as a PR,
including <a href="/en/newsletters/2022/08/24/#updated-silent-payments-pr">updating</a> the implementation later in the year.</p>
<p id="taro">Lightning Labs <a href="/en/newsletters/2022/04/13/#transferable-token-scheme">announced</a> Taro, a proposed protocol
(based on previous proposals) for allowing users to commit to the creation
and transfer of non-bitcoin tokens on Bitcoin’s block chain. Taro is
intended to be used with LN for routable offchain transfers. Similar to
previous proposals for cross-asset transfers on LN, intermediate nodes
that just forward payments won’t need to be aware of the Taro protocol or
the details of the assets being transferred—they’ll just transfer bitcoins
using the same protocol as any other LN payment.</p>
<p id="quantum-safe-keys">April also saw <a href="/en/newsletters/2022/04/20/#quantum-safe-key-exchange">discussion</a> about quantum-safe key
exchange—allowing users to receive bitcoins secured by keys that are
<a href="/en/topics/quantum-resistance/">resistant</a> to attacks by fast quantum
computers that may exist in the future.</p>
<h2 id="may">May</h2>
<p id="musig2">The <a href="/en/topics/musig/">MuSig2</a> protocol for creating <a href="/en/topics/multisignature/">schnorr
multisignatures</a> saw several developments in 2022.
A <a href="/en/newsletters/2022/04/13/#musig2-proposed-bip">proposed BIP</a> received significant <a href="/en/newsletters/2022/05/04/#musig2-implementation-notes">feedback</a> in May. Later, in October, researchers discovered a
<a href="/en/newsletters/2022/10/19/#musig2-security-vulnerability">vulnerability</a> in some ways the protocol could be used,
which the researchers planned to fix in an updated version.</p>
<p id="package-relay">A draft BIP for <a href="/en/topics/package-relay/">package relay</a> was
<a href="/en/newsletters/2022/05/25/#package-relay-proposal">posted</a> by Gloria Zhao in May. Package relay
fixes a significant problem with Bitcoin Core’s <a href="/en/topics/cpfp/">CPFP fee bumping</a> where individual nodes will only accept a fee-bumping child
transaction if its parent transaction pays a feerate above the node’s
dynamic minimum mempool fee. This makes CPFP insufficiently reliable
for protocols depending on presigned transactions, such as many contract
protocols (including the current LN protocol). Package relay allows a
parent and child transaction to be evaluated as a single unit,
eliminating the problem—although not eliminating other related
problems such as <a href="/en/topics/transaction-pinning/">transaction pinning</a>.
Additional discussion of package relay <a href="/en/newsletters/2022/06/15/#continued-package-relay-bip-discussion">ocurred</a>
in June.</p>
<p id="libbitcoinkernel">May also saw the <a href="/en/newsletters/2022/05/04/#bitcoin-core-24322">first merge</a> for the Bitcoin Kernel
Library Project (libbitcoinkernel), an attempt to separate out as much
of Bitcoin Core’s consensus code as possible into a separate library,
even if that code still has some non-consensus code attached.
Long-term, the goal is to trim down libbitcoinkernel until it contains
only consensus code, making it easy for other projects to use that code
or for auditors to analyze changes to Bitcoin Core’s consensus logic.
Several additional libbitcoinkernel PRs would be merged through the
year.</p>
<div class="callout" id="releases">
<h3 id="summarymajor-releases-of-popular-infrastructure-projects">2022 summary<br />Major releases of popular infrastructure projects</h3>
<ul>
<li id="eclair-0-7-0" class="anchor-list">
<p><a href="#eclair-0-7-0" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/02/02/#eclair-0-7-0">Eclair 0.7.0</a> added support for <a href="/en/topics/anchor-outputs/">anchor
outputs</a>, relaying <a href="/en/topics/onion-messages/">onion messages</a>, and using the PostgreSQL database in production.</p>
</li>
<li id="btcpay-server-1-4" class="anchor-list">
<p><a href="#btcpay-server-1-4" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/03/02/#btcpay-server-1-4-6">BTCPay Server 1.4</a> added support for <a href="/en/topics/cpfp/">CPFP fee
bumping</a>, the ability to use additional features of LN
URLs, plus multiple UI improvements.</p>
</li>
<li id="ldk-0-0-105" class="anchor-list">
<p><a href="#ldk-0-0-105" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/03/09/#ldk-0-0-105">LDK 0.0.105</a> added support for phantom node payments and
better probabalistic payment pathfinding.</p>
</li>
<li id="bdk-0-17-0" class="anchor-list">
<p><a href="#bdk-0-17-0" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/03/30/#bdk-0-17-0">BDK 0.17.0</a> made it easier to derive addresses even when
the wallet is offline.</p>
</li>
<li id="bitcoin-core-23-0" class="anchor-list">
<p><a href="#bitcoin-core-23-0" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/04/27/#bitcoin-core-23-0">Bitcoin Core 23.0</a> provided <a href="/en/topics/output-script-descriptors/">descriptor</a> wallets by default for new wallets and also allowed
descriptor wallets to easily support receiving to <a href="/en/topics/bech32/">bech32m</a> addresses using <a href="/en/topics/taproot/">taproot</a>.</p>
</li>
<li id="core-lightning-0-11-0" class="anchor-list">
<p><a href="#core-lightning-0-11-0" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/04/27/#core-lightning-0-11-0">Core Lightning 0.11.0</a> added support for multiple active
channels to the same peer and paying <a href="/en/topics/stateless-invoices/">stateless invoices</a>.</p>
</li>
<li id="rust-bitcoin-0-28" class="anchor-list">
<p><a href="#rust-bitcoin-0-28" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/04/27/#rust-bitcoin-0-28">Rust Bitcoin 0.28</a> added support for <a href="/en/topics/taproot/">taproot</a> and improved related APIs, such as those for <a href="/en/topics/psbt/">PSBTs</a>.</p>
</li>
<li id="btcpay-server-1-5-1" class="anchor-list">
<p><a href="#btcpay-server-1-5-1" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/05/04/#btcpay-server-1-5-1">BTCPay Server 1.5.1</a> added a new main-page dashboard,
a new transfer processors feature, and the ability to allow pull
payments and refunds to be automatically approved.</p>
</li>
<li id="ldk-0-0-108-and-0-0-107" class="anchor-list">
<p><a href="#ldk-0-0-108-and-0-0-107" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/06/22/#ldk-0-0-108">LDK 0.0.108 and 0.0.107</a> added support for <a href="/en/topics/large-channels/">large
channels</a> and <a href="/en/topics/zero-conf-channels/">zero-conf channels</a> in addition to providing code that allows mobile
clients to sync network routing information (gossip) from a server.</p>
</li>
<li id="bdk-0-19-0" class="anchor-list">
<p><a href="#bdk-0-19-0" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/06/22/#bdk-0-19-0">BDK 0.19.0</a> added experimental support for
<a href="/en/topics/taproot/">taproot</a> through <a href="/en/topics/output-script-descriptors/">descriptors</a>,
<a href="/en/topics/psbt/">PSBTs</a>, and other sub-systems. It also added a new <a href="/en/topics/coin-selection/">coin
selection</a> algorithm.</p>
</li>
<li id="lnd-0-15-0-beta" class="anchor-list">
<p><a href="#lnd-0-15-0-beta" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/06/29/#lnd-0-15-0-beta">LND 0.15.0-beta</a> added support for invoice metadata
which can be used by other programs (and potentially future versions
of LND) for <a href="/en/topics/stateless-invoices/">stateless invoices</a> and adds
support to the internal wallet for receiving and spending bitcoins to
<a href="/en/topics/taproot/">P2TR</a> keyspend outputs, along with experimental
<a href="/en/topics/musig/">MuSig2</a> support.</p>
</li>
<li id="rust-bitcoin-0-29" class="anchor-list">
<p><a href="#rust-bitcoin-0-29" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/08/17/#rust-bitcoin-0-29">Rust Bitcoin 0.29</a> added <a href="/en/topics/compact-block-relay/">compact block relay</a> data structures (<a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki">BIP152</a>) and improvements to
<a href="/en/topics/taproot/">taproot</a> and <a href="/en/topics/psbt/">PSBT</a> support.</p>
</li>
<li id="core-lightning-0-12-0" class="anchor-list">
<p><a href="#core-lightning-0-12-0" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/08/24/#core-lightning-0-12-0">Core Lightning 0.12.0</a> added a new <code class="highlighter-rouge">bookkeeper</code> plugin,
a <code class="highlighter-rouge">commando</code> plugin, and support for <a href="/en/topics/static-channel-backups/">static channel backups</a>, plus explicitly began allowing peers the
ability to open <a href="/en/topics/zero-conf-channels/">zero-conf channels</a> to your
node.</p>
</li>
<li id="lnd-0-15-1-beta" class="anchor-list">
<p><a href="#lnd-0-15-1-beta" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/08/31/#lnd-0-15-1-beta">LND 0.15.1-beta</a> added support for <a href="/en/topics/zero-conf-channels/">zero-conf
channels</a>, channel aliases, and began using
<a href="/en/topics/taproot/">taproot</a> addresses everywhere.</p>
</li>
<li id="ldk-0-0-111" class="anchor-list">
<p><a href="#ldk-0-0-111" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/09/14/#ldk-0-0-111">LDK 0.0.111</a> adds support for creating, receiving, and
relaying <a href="/en/topics/onion-messages/">onion messages</a>.</p>
</li>
<li id="core-lightning-22-11" class="anchor-list">
<p><a href="#core-lightning-22-11" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/12/07/#core-lightning-22-11">Core Lightning 22.11</a> began using a new version
numbering scheme and added a new plugin manager.</p>
</li>
<li id="libsecp256k1-0-2-0" class="anchor-list">
<p><a href="#libsecp256k1-0-2-0" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/12/14/#libsecp256k1-0-2-0">libsecp256k1 0.2.0</a> was the first tagged release of
this widely-used library for Bitcoin-related cryptographic operations.</p>
</li>
<li id="bitcoin-core-24-0-1" class="anchor-list">
<p><a href="#bitcoin-core-24-0-1" class="anchor-list-link">●</a> <a href="/en/newsletters/2022/12/14/#bitcoin-core-24-0-1">Bitcoin Core 24.0.1</a> added an option for configuring the
node’s <a href="/en/topics/replace-by-fee/">Replace-By-Fee</a> (RBF) policy, a new <code class="highlighter-rouge">sendall</code> RPC
for easily spending all of a wallet’s funds in a single transaction, a
<code class="highlighter-rouge">simulaterawtransaction</code> RPC that can be used to verify how a
transaction will effect a wallet, and the ability to create watch-only
<a href="/en/topics/output-script-descriptors/">descriptors</a> containing <a href="/en/topics/miniscript/">miniscript</a> expressions for improved forward compatibility with other
software.</p>
</li>
</ul>
</div>
<h2 id="june">June</h2>
<p id="ln-meet">In June, LN developers <a href="/en/newsletters/2022/06/15/#summary-of-ln-developer-meeting">met</a> to discuss the future of
protocol development. Topics discussed included <a href="/en/topics/taproot/">taproot</a>-based LN channels, <a href="/en/topics/tapscript/">tapscript</a> and
<a href="/en/topics/musig/">MuSig2</a> (including recursive MuSig2), updating the gossip
protocol for announcing new and changed channels, <a href="/en/topics/onion-messages/">onion messages</a>, <a href="/en/topics/rendez-vous-routing/">blinded paths</a>, probing and balance
sharing, <a href="/en/topics/trampoline-payments/">trampoline routing</a>, and the
<a href="/en/topics/offers/">offers</a> and LNURL protocols.</p>
<h2 id="july">July</h2>
<p id="onion-message-limiting">In July, Bastien Teinturier <a href="/en/newsletters/2022/07/06/#onion-message-rate-limiting">posted</a> a summary of an idea
he attributes to Rusty Russell for rate limiting <a href="/en/topics/onion-messages/">onion messages</a> in order to prevent denial-of-service attacks. However,
Olaoluwa Osuntokun suggested reconsideration of his March
<a href="/en/newsletters/2022/03/09/#paying-for-onion-messages">proposal</a> for preventing abuse of onion messages by
charging for data relay. It seemed that most developers in the
discussion preferred to attempt rate limiting before adding additional
fees to the protocol.</p>
<p id="miniscript-descriptors">This month Bitcoin Core also <a href="/en/newsletters/2022/07/20/#bitcoin-core-24148">merged a pull request</a>
adding watch-only support for <a href="/en/topics/output-script-descriptors/">output script descriptors</a> written in <a href="/en/topics/miniscript/">miniscript</a>. A future PR is
expected to allow the wallet to create signatures for spending
miniscript-based descriptors. As other wallets and signing devices
implement miniscript support, it should become easier for policies to be
transferred between wallets or for multiple wallets to cooperate in
spending bitcoins, such as multisig policies or policies involving
different signers for different occasions (e.g. fallback signers).</p>
<h2 id="august">August</h2>
<p id="dual-funding">In August, Eclair <a href="/en/newsletters/2022/08/17/#eclair-2273">merged support</a> for the
interactive funding protocol, a dependency for the <a href="/en/topics/dual-funding/">dual funding
protocol</a> that allows either (or both) of two nodes
to contribute funds to a new LN channel. Later that month, another
<a href="/en/newsletters/2022/08/31/#eclair-2275">merge</a> brought Eclair experimental support for
dual funding. An open protocol for dual funding can help ensure
merchants have access to channels that allow them to immediately receive
payments from customers.</p>
<p id="jamming">Antoine Riard and Gleb Naumenko <a href="/en/newsletters/2022/08/24/#overview-of-channel-jamming-attacks-and-mitigations">published</a> a guide in
August to <a href="/en/topics/channel-jamming-attacks/">channel jamming attacks</a> and
several proposed solutions. For every channel an attacker controls,
they can make more than a dozen other channels unusable by sending
payments that never complete—meaning the attacker doesn’t need to pay
any direct costs. The problem has been known since 2015 but no
previously proposed solution has gained widespread acceptance. In
November, Clara Shikhelman and Sergei Tikhomirov would publish their own
<a href="/en/newsletters/2022/11/16/#paper-about-channel-jamming-attacks">paper</a> with analysis and a proposed solution based on
small upfront fees and automated reputation-based referrals.
Subsequently, Riard <a href="/en/newsletters/2022/11/30/#reputation-credentials-proposal-to-mitigate-ln-jamming-attacks">published</a> an alternative solution
involving non-tradable node-specific tokens. In December, Joost Jager
would <a href="/en/newsletters/2022/12/14/#local-jamming-to-prevent-remote-jamming">announce</a> a “simple but imperfect” utility that
could help nodes mitigate some problems with jamming without requiring
any changes to the LN protocol.</p>
<p class="center"><img src="/img/posts/2020-12-ln-jamming-attacks.png" alt="Illustration of the two types of channel jamming attacks" /></p>
<p id="dlc-bls">Lloyd Fournier <a href="/en/newsletters/2022/08/17/#using-bitcoin-compatible-bls-signatures-for-dlcs">wrote</a> about the benefits of having
<a href="/en/topics/discreet-log-contracts/">DLC</a> oracles make their attestations using Boneh-Lynn-Shacham
(<a href="https://en.wikipedia.org/wiki/BLS_digital_signature">BLS</a>) signatures. Bitcoin does not support BLS signatures and a
soft fork would be required to add them, but Fournier links to a paper
he co-authored that describes how information can be securely extracted
from a BLS signature and used with Bitcoin-compatible <a href="/en/topics/adaptor-signatures/">signature
adaptors</a> without any changes to Bitcoin.
This would allow “stateless” oracles where the parties to a contract
(but not the oracle) could privately agree on what information they
wanted the oracle to attest to, e.g. by specifying a program written in
any programming language they knew the oracle would run. They could then
allocate their deposit funds according to the contract without even
telling the oracle that they were planning to use it. When it came time
to settle the contract, each of the parties could run the program
themselves and, if they all agreed on the outcome, settle the contract
cooperatively without involving the oracle at all. If they didn’t
agree, any one of them could send the program to the oracle (perhaps
with a small payment for its service) and receive back a BLS attestation
to the program source code and the value returned by running it. The
attestation could be transformed into signatures that would allow
settling the DLC on chain. As with current DLC contracts, the oracle
would not know which onchain transactions were based on its BLS
signatures.</p>
<div class="callout" id="optech">
<h3 id="summarybitcoin-optech">2022 summary<br />Bitcoin Optech</h3>
<p>In Optech’s fifth year, we published 51 weekly <a href="/en/newsletters/">newsletters</a>, added 11
new pages to our <a href="/en/topics/">topics index</a>. Altogether, Optech published over
70,000 words about Bitcoin software research and development this year,
the rough equivalent of a 200-page book. <!-- wc -w
_posts/en/newsletters/2022-* ; a typical book has about 350 words per page --></p>
</div>
<h2 id="september">September</h2>
<p id="fee-ratecards">Lisa Neigut <a href="/en/newsletters/2022/09/28/#ln-fee-ratecards">posted</a> to the Lightning-Dev mailing
list a proposal for fee ratecards that would allow a node to advertise
four tiered rates for forwarding fees. Better advertisement of
forwarding fees, including the ability to set negative fees in some
cases, could help ensure forwarding nodes had enough capacity to relay
payments towards their ultimate destination. Developer ZmnSCPxj, who
had <a href="/en/newsletters/2022/06/15/#using-routing-fees-to-signal-liquidity">posted</a> his own fee-based solution for improving
routing earlier in the year, described a simple way to use ratecards,
“you can model a rate card as four separate channels between the same
two nodes, with different costs each. If the path at the lowest cost
fails, you just try another route that may have more hops but lower
effective cost, or else try the same channel at a higher cost.” An
alternative method for payment flow control was <a href="/en/newsletters/2022/10/05/#ln-flow-control">suggested</a> by René Pickhardt.</p>
<h2 id="october">October</h2>
<p id="v3-tx-relay">In October, Glora Zhao <a href="/en/newsletters/2022/10/05/#proposed-new-transaction-relay-policies-designed-for-ln-penalty">proposed</a> allowing transactions that
used version number 3 to use a modified set of transaction relay
policies. These policies are based on experience using <a href="/en/topics/cpfp/">CPFP</a> and <a href="/en/topics/replace-by-fee/">RBF</a>, plus ideas for <a href="/en/topics/package-relay/">package relay</a>, and are designed to help preventing <a href="/en/topics/transaction-pinning/">pinning attacks</a> against two-party contract protocols like LN—ensuring
that users can promptly get transactions confirmed for closing channels,
settling payments (<a href="/en/topics/htlc/">HTLCs</a>), and enforcing misbehavior
penalties. Greg Sanders would <a href="/en/newsletters/2022/10/26/#ephemeral-anchors">follow up</a> later in
the month with an additional proposal for <em>ephemeral anchors</em>, a
simplified form of the <a href="/en/topics/anchor-outputs/">anchor outputs</a> already
usable with most LN implementations.</p>
<p id="async-payments">Eclair added <a href="/en/newsletters/2022/10/05/#eclair-2435">support</a> for a basic form of async payments
when <a href="/en/topics/trampoline-payments/">trampoline relay</a> is used. Async
payments would allow paying an offline node (such as a mobile wallet)
without trusting a third-party with the funds. The ideal mechanism for
async payments depends on <a href="/en/topics/ptlc/">PTLCs</a>, but a partial
implementation just requires a third party to delay forwarding the funds
until the offline node comes back online. Trampoline nodes can provide
that delay and so this PR makes use of them to allow experimentation
with async payments</p>
<p id="parsing-bugs">October also saw the <a href="/en/newsletters/2022/10/19/#block-parsing-bug-affecting-btcd-and-lnd">first</a> of two block parsing bugs that
affected multiple applications. An accidentally triggered bug in BTCD
prevented it and downstream program LND from processing the latest
blocks. This could have led to users losing funds, although no such
problems were reported. A <a href="/en/newsletters/2022/11/09/#block-parsing-bug-affecting-multiple-software">second</a> related bug, this time
deliberately triggered, affected BTCD and LND again, plus users of some
versions of Rust-Bitcoin. Again, there was a potential for users to
lose money, although we are unaware of any reported incidents.</p>
<p id="zk-rollups">John Light <a href="/en/newsletters/2022/10/19/#validity-rollups-research">posted</a> a research report he prepared about
validity rollups—a type of sidechain where the current sidechain state
is compactly stored on the mainchain. An owner of sidechain bitcoins can
use the state stored on the mainchain to prove how many sidechain
bitcoins they control. By submitting a mainchain transaction with a
validity proof, they can withdraw bitcoins they own from the sidechain
even if the operators or miners of the sidechain try to prevent the
withdrawal. Light’s research describes validity rollups in depth, looks
at how support for them could be added to Bitcoin, and examines various
concerns with their implementation.</p>
<p id="v2-transport">The <a href="https://github.com/dhruv/bips/blob/bip324/bip-0324.mediawiki">BIP324</a> proposal for an <a href="/en/newsletters/2022/10/19/#bip324-update">encrypted v2 P2P transport
protocol</a> received an update and mailing list
discussion for the first time in three years. Encrypting the transport
of unconfirmed transactions can help hide their origin from eavesdroppers
who control many internet relays (e.g. large ISPs and governments). It
can also help detect tampering and possibly make <a href="/en/topics/eclipse-attacks/">eclipse attacks</a> more difficult.</p>
<p id="core-meet">A meeting of Bitcoin protocol developers had several sessions
<a href="/en/newsletters/2022/10/26/#coredev-tech-transcripts">transcribed</a> by Bryan Bishop, including discussions
about <a href="/en/topics/v2-p2p-transport/">transport encryption</a>, transaction fees
and <a href="/en/topics/fee-sniping/">economic security</a>, the FROST <a href="/en/topics/threshold-signature/">threshold
signature</a> scheme, the sustainability of
using GitHub for source code and development discussion hosting,
including provable specifications in BIPs, <a href="/en/topics/package-relay/">package relay</a> and <a href="/en/topics/version-3-transaction-relay/">v3 transaction relay</a>, the
Stratum version 2 mining protocol, and getting code merged into Bitcoin
Core and other free software projects.</p>
<div class="callout" id="softforks">
<h3 id="summarysoft-fork-proposals">2022 summary<br />Soft fork proposals</h3>
<p>January began with Jeremy Rubin <a href="/en/newsletters/2022/01/19/#irc-meeting">holding</a> the first of
several IRC meetings to review and discuss the
<a href="/en/topics/op_checktemplateverify/">OP_CHECKTEMPLATEVERIFY</a> (CTV) soft fork
proposal. Meanwhile, Peter Todd <a href="/en/newsletters/2022/01/19/#mailing-list-discussion">posted</a> several concerns
with the proposal to the Bitcoin-Dev mailing list, most notably
expressing concern that it didn’t seem to benefit nearly all Bitcoin
users, as he believes previously soft forks have done.</p>
<p>Lloyd Fournier <a href="/en/newsletters/2022/02/02/#improving-dlc-efficiency-by-changing-script">posted</a> to the DLC-Dev and Bitcoin-Dev
mailing lists about how the CTV opcode could radically reduce the number
of signatures required to create certain <a href="/en/topics/discreet-log-contracts/">Discreet Log Contracts</a> (DLCs), as well as reduce the number of some other operations.
Jonas Nick noted that a similar optimization is also possible using the
proposed <a href="/en/topics/sighash_anyprevout/">SIGHASH_ANYPREVOUT</a> (APO) signature
hash mode.</p>
<p>Russell O’Connorr <a href="/en/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo">proposed</a> an alternative to both CTV
and APO—a soft fork adding an <code class="highlighter-rouge">OP_TXHASH</code> opcode and an
<a href="/en/topics/op_checksigfromstack/">OP_CHECKSIGFROMSTACK</a> (CSFS) opcode. The
TXHASH opcode would specify which parts of a spending transaction should
be serialized and hashed, with the hash digest being put on the
evaluation stack for later opcodes to use. The CSFS opcode would specify
a public key and require a corresponding signature over particular data
on the stack—such as the computed digest of the transaction created by
TXHASH. This would allow emulation of CTV and APO in a way that might
be simpler, more flexible, and easier to extend through other
subsequent soft forks.</p>
<p>In February, Rusty Russell would <a href="/en/newsletters/2022/02/16/#simplified-alternative-to-op-txhash">propose</a> <code class="highlighter-rouge">OP_TX</code>, an
even simpler version of <code class="highlighter-rouge">OP_TXHASH</code>. Meanwhile, Jeremy Rubin
<a href="/en/newsletters/2022/02/23/#ctv-signet">published</a> parameters and code for a <a href="/en/topics/signet/">signet</a> with CTV
activated. This simplifies public experimentation with the proposed
opcode and makes it much easier to test compatibility between different
software using the code. Also in February, developer ZmnSCPxj proposed
a new <code class="highlighter-rouge">OP_EVICT</code> opcode as an alternative to the
<code class="highlighter-rouge">OP_TAPLEAF_UPDATE_VERIFY</code> (TLUV) opcode proposed in 2021. Like TLUV,
EVICT is focused on use cases where more than two users share ownership
of a single UTXO, such as <a href="/en/topics/joinpools/">joinpools</a>, <a href="/en/topics/channel-factories/">channel
factories</a>, and certain <a href="/en/topics/covenants/">covenants</a>. ZmnSCPxj would later <a href="/en/newsletters/2022/03/16/#looping-folding">propose</a> a different new opcode,
<code class="highlighter-rouge">OP_FOLD</code>, as a more general construct from which EVICT-like behavior
could be built (though that would require some other Script language
changes).</p>
<p>By March, the discussion about CTV and newer opcode proposals led to a
<a href="/en/newsletters/2022/03/09/#limiting-script-language-expressiveness">discussion</a> about limiting the expressiveness of
Bitcoin’s Script language, mainly to prevent <em>recursive
covenants</em>—conditions that would need to be fulfilled in every
transaction re-spending those bitcoins or any bitcoins merged with it
for perpetuity. Concerns included a loss of censorship resistance,
enabling <a href="/en/topics/sidechains/">drivechains</a>, encouraging unnecessary
computation, and making it possible for users to accidentally lose coins
to recursive covenants.</p>
<p>March also saw yet another idea for a soft fork change to Bitcoin’s
Script language, this time to allow future transactions to opt-in to a
completely different language based on Lisp. Anthony Towns
<a href="/en/newsletters/2022/03/16/#using-chia-lisp">proposed</a> the idea and described how it might be
better than both Script and a previously-proposed replacement:
<a href="/en/topics/simplicity/">Simplicity</a>.</p>
<p>In April, Jeremy Rubin <a href="/en/newsletters/2022/04/27/#discussion-about-activating-ctv">posted</a> to the Bitcoin-Dev mailing
list his plan to release software that will allow miners to begin
signaling whether they intend to enforce the <a href="https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki">BIP119</a> rules for the
proposed CTV opcode. This spurred discussion about CTV and similar
proposals, such as APO. Rubin later announced he wouldn’t be releasing
compiled software for activating CTV at the present time as he and other
CTV supporters evaluated the feedback they’d received.</p>
<p>In May, Rusty Russell <a href="/en/newsletters/2022/05/18/#updated-op-tx-proposal">updated</a> his <code class="highlighter-rouge">OP_TX</code> proposal. The
original proposal would allow recursive covenants, which elicited the
concerns mentioned earlier in this section. Instead, Russell proposed
an initial version of TX that was limited to permitting the behavior of
CTV, which had been specifically designed to prevent recursive
covenants. This new version of TX could be incrementally updated in the
future to provide additional features, making it more powerful but also
allowing those new features to be independently analyzed. Additional
discussion in May <a href="/en/newsletters/2022/05/18/#when-would-enabling-op-cat-allow-recursive-covenants">examined</a> the <code class="highlighter-rouge">OP_CAT</code> opcode (removed
from Bitcoin in 2010), which some developers occasionally suggest might
be a candidate for adding back in the future.</p>
<p>In September, Jeremy Rubin <a href="/en/newsletters/2022/09/21/#creating-drivechains-with-apo-and-a-trusted-setup">described</a> how a trusted setup
procedure could be combined with the proposed APO feature to implement
behavior similar to that proposed by <a href="/en/topics/sidechains/">drivechains</a>.
Preventing the implementation of drivechains on Bitcoin was one of the
reasons developer ZmnSCPxj suggested earlier in the year that full node
operators might want to oppose soft forks that enable recursive
covenants.</p>
<p>Also in September, Anthony Towns <a href="/en/newsletters/2022/09/28/#bitcoin-implementation-designed-for-testing-soft-forks-on-signet">announced</a> a
Bitcoin implementation designed specifically for testing soft forks on
<a href="/en/topics/signet/">signet</a>. Based on Bitcoin Core, Towns’s code will
enforce rules for soft fork proposals with high-quality specifications
and implementations, making it simpler for users to experiment with the
proposed changes—including comparing changes to each other or seeing
how they interact. Towns also plans to include proposed major changes
to transaction relay policy (such as <a href="/en/topics/package-relay/">package relay</a>).</p>
<p>In November, Salvatore Ingala <a href="/en/newsletters/2022/11/16/#general-smart-contracts-in-bitcoin-via-covenants">posted</a> to the Bitcoin-Dev
mailing list a proposal for a new type of covenant (requiring a soft
fork) that would allow using merkle trees to create smart contracts that
can carry state from one onchain transaction to another. This would be
similar in capability to smart contracts used on some other
cryptocurrency systems but would be compatible with Bitcoin’s existing
UTXO-based system.</p>
</div>
<h2 id="november">November</h2>
<p id="fat-errors">November saw Joost Jager <a href="/en/newsletters/2022/11/02/#ln-routing-failure-attribution">update</a> a proposal from 2019 to
improve error reporting in LN for failed payments. The error would
report the identity of a channel where a payment failed to be forwarded
by a node so that the spender could avoid using channels involving that
node for a limited time. Several LN implementations would update their
code to support the proposal, even if they didn’t immediately begin
using it themselves, including <a href="/en/newsletters/2022/11/09/#eclair-2441">Eclair</a> and <a href="/en/newsletters/2022/11/16/#core-lightning-5698">Core
Lightning</a>.</p>
<h2 id="december">December</h2>
<p id="ln-mod">In December, protocol developer John Law posted to the Lightning-Dev
mailing list his third major proposal for the year. Like his previous
two proposals, he suggested new ways LN offchain transactions could be
designed to enable new features without requiring any changes to
Bitcoin’s consensus code. Altogether, Law proposed ways casual LN users
could <a href="/en/newsletters/2022/10/12/#ln-with-long-timeouts-proposal">remain offline</a> for potentially months at a time,
<a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html">separating</a> the enforcement for specific payments from the
management of all settled funds to improve compatibility with
<a href="/en/topics/watchtowers/">watchtowers</a>, and <a href="/en/newsletters/2022/12/14/#factory-optimized-ln-protocol-proposal">optimizing</a> LN
channels for use in <a href="/en/topics/channel-factories/">channel factories</a> that
could significantly decrease the onchain costs to use LN.</p>
<p><em>We thank all of the Bitcoin contributors named above, plus the many
others whose work was just as important, for another incredible year of
Bitcoin development. The Optech newsletter will return to its regular
Wednesday publication schedule on January 4th.</em></p>Bitcoin OptechThis special edition of the Optech Newsletter summarizes notable developments in Bitcoin during all of 2022.Bitcoin Optech Newsletter #2302022-12-14T00:00:00+00:002022-12-14T00:00:00+00:00https://bitcoinops.org/en/newsletters/2022/12/2022-12-14-newsletter<p>This week’s newsletter summarizes a proposal for a modified version of
LN that may improve compatibility with channel factories, describes
software for mitigating some effects of channel jamming attacks without
changing the LN protocol, and links to a website for tracking unsignaled
transaction replacements. Also included are our regular sections with
announcements of new client and service software, summaries of popular
questions and answers on the Bitcoin Stack Exchange, and descriptions of
notable changes to popular Bitcoin infrastructure software.</p>
<h2 id="news">News</h2>
<ul>
<li id="factory-optimized-ln-protocol-proposal" class="anchor-list">
<p><a href="#factory-optimized-ln-protocol-proposal" class="anchor-list-link">●</a> <strong>Factory-optimized LN protocol proposal:</strong> John Law <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003782.html">posted</a> to the Lightning-Dev mailing list the description of a
protocol optimized for creating <a href="/en/topics/channel-factories/">channel factories</a>. Channel factories allow multiple users to trustlessly
open multiple channels between pairs of users with only a single
transaction onchain. For example, 20 users could cooperate to create
an onchain transaction about 10 times larger than a normal two-party
open but which opened a total of 190 channels<!-- n=20 ; n*(n - 1)/2
-->.</p>
<p>Law notes that the existing LN channel protocol (commonly called
LN-penalty) creates two problems for channels opened from within a
factory:</p>
<ul>
<li id="long-required-htlc-expiries" class="anchor-list">
<p><a href="#long-required-htlc-expiries" class="anchor-list-link">●</a> <em>Long required HTLC expiries:</em> trustlessness requires that any
participant in a factory be able to exit it and regain exclusive
control over their funds onchain. This is accomplished by the
participant publishing the current state of balances in the
factory onchain. However, a mechanism is needed to prevent the
participant from publishing an earlier state, e.g. one where they
controlled a greater amount of money. The original factory
proposal accomplishes this by using one or more timelocked
transactions that ensure more recent states can be confirmed more
quickly than outdated states.</p>
<p>A consequence of this, described by Law, is that any LN payment
(<a href="/en/topics/htlc/">HTLC</a>) that is routed through a channel in a
channel factory needs to provide enough time for the latest
state timelock to expire so the factory can be unilaterally
closed. Worse, this applies each time a payment is forwarded
through a factory. For example, if a payment is forwarded
through 10 factories each with a 1-day expiry, it’s possible that
a payment could be <a href="/en/topics/channel-jamming-attacks/">jammed</a> by
accident or on purpose for 10 days (or longer, depending on
other HTLC settings).</p>
</li>
<li id="all-or-nothing" class="anchor-list">
<p><a href="#all-or-nothing" class="anchor-list-link">●</a> <em>All or nothing:</em> for factories to truly achieve their best
efficiencies, all of their channels also need to be cooperatively
closed in a single onchain transaction. Cooperative closes aren’t
possible if any of the original participants becomes
unresponsive—and the chance of a participant becoming
unresponsive approaches 100% as the number of participants
increases, limiting the maximum benefit factories can provide.</p>
<p>Law cites previous work in allowing factories to remain
operational even if one participant wants to leave or,
conversely, one participant becomes unresponsive, such as the
proposals for <code class="highlighter-rouge">OP_TAPLEAF_UPDATE_VERIFY</code> and <code class="highlighter-rouge">OP_EVICT</code> (see
Newsletters <a href="/en/newsletters/2021/09/15/#covenant-opcode-proposal">#166</a> and <a href="/en/newsletters/2022/03/02/#proposed-opcode-to-simplify-shared-utxo-ownership">#189</a>).</p>
</li>
</ul>
<p>Three proposed protocols are presented by Law to address the
concerns. All derive from a previous proposal by Law <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003732.html">posted</a> in October for <em>tunable penalties</em>—the ability to separate the
management of the enforcement mechanism (penalties) from the
management of other funds. That previous proposal has not yet
received any discussion on the Lightning-Dev mailing list. As of
this writing, Law’s new proposal has also not received any
discussion. If the proposals are sound, they would have the
advantage over other proposals of not requiring any changes to
Bitcoin’s consensus rules.</p>
</li>
<li id="local-jamming-to-prevent-remote-jamming" class="anchor-list">
<p><a href="#local-jamming-to-prevent-remote-jamming" class="anchor-list-link">●</a> <strong>Local jamming to prevent remote jamming:</strong> Joost Jager
<a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-December/003781.html">posted</a> to the Lightning-Dev mailing list a link and
explanation for his project, <a href="https://github.com/lightningequipment/circuitbreaker">CircuitBreaker</a>. This program,
designed to be compatible with LND, enforces limits on the number of
pending payments (<a href="/en/topics/htlc/">HTLCs</a>) the local node will forward on
behalf of each of its peers. For example, consider the worst case
HTLC jamming attack:</p>
<p><img src="/img/posts/2020-12-ln-jamming-attacks.png" alt="Illustration of two different jamming attacks" /></p>
<p>With the current LN protocol, Alice is fundamentally limited to
concurrently forwarding a maximum of <a href="https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#rationale-7">483 pending HTLCs</a>. If she
instead uses CircuitBreaker to limit her channel with Mallory to
10 concurrent pending HTLC forwards, her downstream channel with Bob
(not visualized) and all other channels in this circuit will be
protected from all but those first 10 HTLCs that Mallory keeps
pending. This may significantly reduce the effectiveness of
Mallory’s attack by requiring she open many more channels to block
the same number of HTLC slots, which may increase the cost of the
attack by requiring she pay more onchain fees.</p>
<p>Although CircuitBreaker was originally implemented to simply refuse
to accept any HTLCs in any channel which exceeded its limit, Jager
notes that he recently implemented an optional additional mode which
puts any HTLCs in a queue rather than immediately refusing or
forwarding them. When the number of concurrent pending HTLCs in a
channel drops below the channel limit, CircuitBreaker forwards the
oldest non-expired HTLC from the queue. Jager describes two
advantages of this approach:</p>
<ul>
<li id="backpressure" class="anchor-list">
<p><a href="#backpressure" class="anchor-list-link">●</a> <em>Backpressure:</em> if a node in the middle of a circuit refuses an
HTLC, all nodes in the circuit (not just those further down the
circuit) can use that HTLC’s slot and funds to forward other
payments. That means there’s limited incentive for Alice to
refuse more than 10 HTLCs from Mallory—she can simply hope that
some later node in the circuit will run CircuitBreaker or
equivalent software.</p>
<p>However, if a later node (say Bob) uses CircuitBreaker to queue
excess HTLCs, then Alice could still have her HTLC slots or
funds exhausted by Mallory even though Bob and later nodes in
the circuit retain the same benefits as now (with the exception
of possibly increased channel closing costs for Bob in some
cases; see Jager’s email or the CircuitBreaker documentation for
details). This gently pressures Alice into running
CircuitBreaker or something similar.</p>
</li>
<li id="failure-attribution" class="anchor-list">
<p><a href="#failure-attribution" class="anchor-list-link">●</a> <em>Failure attribution:</em> the current LN protocol allows (in many
cases) a spender to identify which channel refused to forward an
HTLC. Some spender software tries to avoid using those channels
in future HTLCs for a certain amount of time. In the case of
refusing HTLCs from malicious actors like Mallory, this obviously
doesn’t matter, but if a node running CircuitBreaker refuses HTLCs
from honest spenders, this may not only reduce its income from
those refused HTLCs but also the income it would’ve received from
subsequent payment attempts.</p>
<p>However, the LN protocol doesn’t currently have a widely
deployed way to determine which channel delayed an HTLC, so it’s
less consequential in this regard to delay forwarding an HTLC
than it is to outright refuse to forward it. Jager notes that
this is changing due to many LN implementations working on
supporting more detailed onion-routed error messages (see
<a href="/en/newsletters/2022/11/02/#ln-routing-failure-attribution">Newsletters #224</a>), so this advantage may
disappear some day.</p>
</li>
</ul>
<p>Jager calls CircuitBreaker, “a simple but imperfect way to deal with
channel jamming and spamming”. Work continues on finding and
deploying a protocol-level change that will more comprehensively
mitigate concerns about jamming attacks, but CircuitBreaker stands
out as a seemingly reasonable solution that’s compatible with the
current LN protocol and which any LND user can deploy immediately on
their forwarding node. CircuitBreaker is MIT licensed and
conceptually simple, so it should be possible to adapt or port for
other LN implementations.</p>
</li>
<li id="monitoring-of-full-rbf-replacements" class="anchor-list">
<p><a href="#monitoring-of-full-rbf-replacements" class="anchor-list-link">●</a> <strong>Monitoring of full-RBF replacements:</strong> developer 0xB10C
<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021258.html">posted</a> to the Bitcoin-Dev mailing list that they’ve
begun providing <a href="https://fullrbf.mempool.observer/">publicly accessible</a> monitoring of
transaction replacements in the mempool of their Bitcoin Core node
that don’t contain the BIP125 signal. Their node allows full-RBF
replacement using the <code class="highlighter-rouge">mempoolfullrbf</code> configuration option (see
<a href="/en/newsletters/2022/07/13/#bitcoin-core-25353">Newsletter #208</a>).</p>
<p>Users and services can use the website as an indicator for which
large mining pools might be currently confirming unsignaled
replacement transactions (if any are doing so). However, we remind
readers that payments received in unconfirmed transactions cannot be
guaranteed even if miners don’t currently seem to be mining
unsignaled replacements.</p>
</li>
</ul>
<h2 id="changes-to-services-and-client-software">Changes to services and client software</h2>
<p><em>In this monthly feature, we highlight interesting updates to Bitcoin
wallets and services.</em></p>
<ul>
<li id="lily-wallet-adds-coin-selection" class="anchor-list">
<p><a href="#lily-wallet-adds-coin-selection" class="anchor-list-link">●</a> <strong>Lily Wallet adds coin selection:</strong>
Lily Wallet <a href="https://github.com/Lily-Technologies/lily-wallet/releases/tag/v1.2.0">v1.2.0</a> adds <a href="/en/topics/coin-selection/">coin selection</a> features.</p>
</li>
<li id="vortex-software-creates-ln-channels-from-a-coinjoin" class="anchor-list">
<p><a href="#vortex-software-creates-ln-channels-from-a-coinjoin" class="anchor-list-link">●</a> <strong>Vortex software creates LN channels from a coinjoin:</strong>
Using <a href="/en/topics/taproot/">taproot</a> and collaborative <a href="/en/topics/coinjoin/">coinjoin</a>
transactions, users have <a href="https://twitter.com/benthecarman/status/1590886577940889600">opened LN channels</a> on Bitcoin mainnet using the
<a href="https://github.com/ln-vortex/ln-vortex">Vortex</a> software.</p>
</li>
<li id="mutiny-demonstrates-ln-node-in-a-browser-poc" class="anchor-list">
<p><a href="#mutiny-demonstrates-ln-node-in-a-browser-poc" class="anchor-list-link">●</a> <strong>Mutiny demonstrates LN node in a browser PoC:</strong>
Using WASM and LDK, developers <a href="https://twitter.com/benthecarman/status/1595395624010190850">demonstrated</a> a
<a href="https://github.com/BitcoinDevShop/mutiny-web-poc">proof-of-concept</a> implementation of an LN node running in a
mobile phone browser.</p>
</li>
<li id="coinkite-launches-binarywatch-org" class="anchor-list">
<p><a href="#coinkite-launches-binarywatch-org" class="anchor-list-link">●</a> <strong>Coinkite launches BinaryWatch.org:</strong>
The <a href="https://binarywatch.org/">BinaryWatch.org</a> website checks binaries from Bitcoin-related projects
and monitors for any changes. The company also operates <a href="https://bitcoinbinary.org/">bitcoinbinary.org</a> a
service that archives <a href="/en/topics/reproducible-builds/">reproducible builds</a> for
Bitcoin-related projects.</p>
</li>
</ul>
<h2 id="selected-qa-from-bitcoin-stack-exchange">Selected Q&A from Bitcoin Stack Exchange</h2>
<p><em><a href="https://bitcoin.stackexchange.com/">Bitcoin Stack Exchange</a> is one of the first places Optech
contributors look for answers to their questions—or when we have a
few spare moments to help curious or confused users. In
this monthly feature, we highlight some of the top-voted questions and
answers posted since our last update.</em></p>
<ul>
<li id="why-is-connecting-to-the-bitcoin-network-exclusively-over-tor-considered-a-bad-practice" class="anchor-list">
<p><a href="#why-is-connecting-to-the-bitcoin-network-exclusively-over-tor-considered-a-bad-practice" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/116146">Why is connecting to the Bitcoin network exclusively over Tor considered a bad practice?</a>
Several answers explain that due to the lower cost of being able to generate many
Tor addresses as compared to IPv4 and IPv6 addresses, a Bitcoin node operator
exclusively using the Tor network could more easily be <a href="/en/topics/eclipse-attacks/">eclipse attacked</a> when compared to operating only on clearnet or with a
combination of <a href="/en/topics/anonymity-networks/">anonymity networks</a>.</p>
</li>
<li id="why-aren-t-3-party-or-more-channels-realistically-possible-in-lightning-today" class="anchor-list">
<p><a href="#why-aren-t-3-party-or-more-channels-realistically-possible-in-lightning-today" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/116257">Why aren’t 3 party (or more) channels realistically possible in Lightning today?</a>
Murch explains that since LN channels currently use the LN penalty mechanism
that allocates <em>all</em> channel funds to a single counterparty in the event of a
breach, extending LN penalty to handle multiple recipients of a justice
transaction may be overly complicated and involve excessive overhead to
implement. He then explains <a href="/en/topics/eltoo/">eltoo’s</a> mechanism and how it might
handle multiparty channels.</p>
</li>
<li id="with-legacy-wallets-deprecated-will-bitcoin-core-be-able-to-sign-messages-for-an-address" class="anchor-list">
<p><a href="#with-legacy-wallets-deprecated-will-bitcoin-core-be-able-to-sign-messages-for-an-address" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/116187">With legacy wallets deprecated, will Bitcoin Core be able to sign messages for an address?</a>
Pieter Wuille distinguishes between Bitcoin Core <a href="/en/newsletters/2020/11/25/#how-will-the-migration-tool-from-a-bitcoin-core-legacy-wallet-to-a-descriptor-wallet-work">deprecating legacy
wallets</a> and the continued support for
older address types like P2PKH addresses even in newer <a href="/en/topics/output-script-descriptors/">descriptor</a> wallets. While message signing is currently only possible for
P2PKH addresses, efforts around <a href="/en/topics/generic-signmessage/">BIP322</a> could
allow for message signing across other address types.</p>
</li>
<li id="how-do-i-set-up-a-time-decay-multisig" class="anchor-list">
<p><a href="#how-do-i-set-up-a-time-decay-multisig" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/116035">How do I set up a time-decay multisig?</a>
User Yoda asks how to set up a time-decaying multisig, a UTXO that is spendable
with a broadening set of pubkeys over time. Michael Folkson provides an
example using <a href="/en/newsletters/2019/11/27/#what-is-the-difference-between-bitcoin-policy-language-and-miniscript">policy</a> and <a href="/en/topics/miniscript/">miniscript</a>, links to related resources, and notes the lack of user-friendly
options currently.</p>
</li>
<li id="when-is-a-miniscript-solution-malleable" class="anchor-list">
<p><a href="#when-is-a-miniscript-solution-malleable" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/116275">When is a miniscript solution malleable?</a>
Antoine Poinsot defines what malleability means in the context of
miniscript, describes static analysis of malleability in miniscript, and walks
through the original question’s malleability example.</p>
</li>
</ul>
<h2 id="releases-and-release-candidates">Releases and release candidates</h2>
<p><em>New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
release candidates.</em></p>
<ul>
<li id="bitcoin-core-24-0-1" class="anchor-list">
<p><a href="#bitcoin-core-24-0-1" class="anchor-list-link">●</a> <a href="https://bitcoincore.org/bin/bitcoin-core-24.0.1/">Bitcoin Core 24.0.1</a> is a major release of the mostly widely used
full node software. Its new features include an option for
configuring the node’s <a href="/en/topics/replace-by-fee/">Replace-By-Fee</a> (RBF) policy, a new
<code class="highlighter-rouge">sendall</code> RPC for easily spending all of a wallet’s funds in a single
transaction (or for otherwise creating transactions with no change
output), a <code class="highlighter-rouge">simulaterawtransaction</code> RPC that can be used to verify how
a transaction will effect a wallet (e.g., for ensuring a coinjoin
transaction only decreases the value of a wallet by fees), the ability
to create watch-only <a href="/en/topics/output-script-descriptors/">descriptors</a> containing
<a href="/en/topics/miniscript/">miniscript</a> expressions for improved forward
compatibility with other software, and the automatic application of
certain setting changes made in the GUI to RPC-based actions. See the
<a href="https://bitcoincore.org/en/releases/24.0.1/">release notes</a> for the full list of new features and bug
fixes.</p>
<p>Note: a version 24.0 was tagged and had its binaries released, but
project maintainers never announced it and instead worked with other
contributors to resolve <a href="https://github.com/bitcoin/bitcoin/milestone/59?closed=1">some last-minute issues</a>, making this release of 24.0.1 the first announced release
of the 24.x branch.</p>
</li>
<li id="libsecp256k1-0-2-0" class="anchor-list">
<p><a href="#libsecp256k1-0-2-0" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin-core/secp256k1/releases/tag/v0.2.0">libsecp256k1 0.2.0</a> is the first tagged release of this widely-used
library for Bitcoin-related cryptographic operations. An
<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021271.html">announcement</a> of the release states, “for a
long time, libsecp256k1’s development only had a master branch,
creating unclarity about API compatibility and stability. Going
forward, we will be creating tagged releases when relevant
improvements are merged, following a semantic versioning scheme. […]
We’re skipping version 0.1.0 because this version number was set in
our autotools build scripts for years, and does not uniquely identify
a set of source files. We will not be creating binary releases, but
will take expected ABI compatibility issues into account for release
notes and versioning.”</p>
</li>
<li id="core-lightning-22-11-1" class="anchor-list">
<p><a href="#core-lightning-22-11-1" class="anchor-list-link">●</a> <a href="https://github.com/ElementsProject/lightning/releases/tag/v22.11.1">Core Lightning 22.11.1</a> is a minor release that temporarily
reintroduces some features that were deprecated in 22.11, as requested
by some downstream developers.</p>
</li>
</ul>
<h2 id="notable-code-and-documentation-changes">Notable code and documentation changes</h2>
<p><em>Notable changes this week in <a href="https://github.com/bitcoin/bitcoin">Bitcoin Core</a>, <a href="https://github.com/ElementsProject/lightning">Core
Lightning</a>, <a href="https://github.com/ACINQ/eclair">Eclair</a>, <a href="https://github.com/lightningdevkit/rust-lightning">LDK</a>,
<a href="https://github.com/lightningnetwork/lnd/">LND</a>, <a href="https://github.com/bitcoin-core/secp256k1">libsecp256k1</a>, <a href="https://github.com/bitcoin-core/HWI">Hardware Wallet
Interface (HWI)</a>, <a href="https://github.com/rust-bitcoin/rust-bitcoin">Rust Bitcoin</a>, <a href="https://github.com/btcpayserver/btcpayserver/">BTCPay
Server</a>, <a href="https://github.com/bitcoindevkit/bdk">BDK</a>, <a href="https://github.com/bitcoin/bips/">Bitcoin Improvement
Proposals (BIPs)</a>, and <a href="https://github.com/lightning/bolts">Lightning BOLTs</a>.</em></p>
<ul>
<li id="bitcoin-core-25934" class="anchor-list">
<p><a href="#bitcoin-core-25934" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin/bitcoin/issues/25934">Bitcoin Core #25934</a> adds an optional <code class="highlighter-rouge">label</code> argument to the
<code class="highlighter-rouge">listsinceblock</code> RPC. Only transactions matching the label will be returned
when a label is specified.</p>
</li>
<li id="lnd-7159" class="anchor-list">
<p><a href="#lnd-7159" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/issues/7159">LND #7159</a> updates the <code class="highlighter-rouge">ListInvoiceRequest</code> and
<code class="highlighter-rouge">ListPaymentsRequest</code> RPCs with new <code class="highlighter-rouge">creation_date_start</code> and
<code class="highlighter-rouge">creation_date_end</code> fields that can be used to filter out invoices and
payments before or after the indicated date and time.</p>
</li>
<li id="ldk-1835" class="anchor-list">
<p><a href="#ldk-1835" class="anchor-list-link">●</a> <a href="https://github.com/lightningdevkit/rust-lightning/issues/1835">LDK #1835</a> adds a fake Short Channel IDentifier (SCID) namespace for intercepted HTLCs, enabling
Lightning Service Providers (LSPs) to create a <a href="/en/topics/jit-routing/">just-in-time</a>
(JIT) channel for end users to receive a lightning payment. This is done
by including fake route hints in end-user invoices that signal to LDK
that this is an intercept forward, similar to
<a href="https://lightningdevkit.org/blog/introducing-phantom-node-payments/">phantom payments</a> (see <a href="/en/newsletters/2022/02/23/#ldk-1199">Newsletter #188</a>). LDK then generates an event,
allowing the LSP the opportunity to open the JIT channel. The LSP can
then forward the payment over the newly opened channel or fail it.</p>
</li>
<li id="bolts-1021" class="anchor-list">
<p><a href="#bolts-1021" class="anchor-list-link">●</a> <a href="https://github.com/lightning/bolts/issues/1021">BOLTs #1021</a> allows onion-routing error messages to contain a
<a href="https://github.com/lightning/bolts/blob/master/01-messaging.md#type-length-value-format">TLV</a> stream, which may be used in the future to include additional
information about the failure. This is a first step towards
implementing <a href="/en/newsletters/2022/11/02/#ln-routing-failure-attribution">fat errors</a> as proposed in <a href="https://github.com/lightning/bolts/issues/1044">BOLTs #1044</a>.</p>
</li>
</ul>
<h2 id="happy-holidays">Happy holidays!</h2>
<p>This is Bitcoin Optech’s final regular newsletter of the year. On
Wednesday, December 21st, we’ll publish our fifth annual year-in-review
newsletter. Regular publication will resume on Wednesday, January 4th.</p>Bitcoin OptechThis week’s newsletter summarizes a proposal for a modified version of LN that may improve compatibility with channel factories, describes software for mitigating some effects of channel jamming attacks without changing the LN protocol, and links to a website for tracking unsignaled transaction replacements. Also included are our regular sections with announcements of new client and service software, summaries of popular questions and answers on the Bitcoin Stack Exchange, and descriptions of notable changes to popular Bitcoin infrastructure software.Bitcoin Optech Newsletter #2292022-12-07T00:00:00+00:002022-12-07T00:00:00+00:00https://bitcoinops.org/en/newsletters/2022/12/2022-12-07-newsletter<p>This week’s newsletter describes an implementation of ephemeral anchors
and includes our regular sections with the summary of a Bitcoin Core PR
Review Club meeting, announcements of new releases and release
candidates, and descriptions of notable changes to popular Bitcoin
infrastructure projects.</p>
<h2 id="news">News</h2>
<ul>
<li id="ephemeral-anchors-implementation" class="anchor-list">
<p><a href="#ephemeral-anchors-implementation" class="anchor-list-link">●</a> <strong>Ephemeral anchors implementation:</strong> Greg Sanders <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021222.html">posted</a> to the Bitcoin-Dev mailing list that he’s implemented his
idea for ephemeral anchors (see <a href="/en/newsletters/2022/10/26/#ephemeral-anchors">Newsletter #223</a>).
<a href="/en/topics/anchor-outputs/">Anchor outputs</a> are an existing technique made
available by Bitcoin Core <a href="/en/topics/cpfp-carve-out/">CPFP carve outs</a> and
used in the LN protocol to ensure that both parties involved in a
contract can <a href="/en/topics/cpfp/">CPFP</a> fee bump a transaction related to that
contract. Anchor outputs have several downsides—some of them
fundamental (see <a href="/en/newsletters/2022/11/02/#anchor-outputs-workaround">Newsletter #224</a>)—but others
that can be addressed.</p>
<p>Ephemeral anchors build on the <a href="/en/topics/version-3-transaction-relay/">v3 transaction relay proposal</a> to allow v3 transactions to include a
zero-value output paying a script that is essentially <code class="highlighter-rouge">OP_TRUE</code>,
which permits that transaction to be CPFP fee bumped by anyone on the
network with a spendable UTXO. The fee-bumping child transaction
can itself be RBF fee bumped by anyone else with a spendable UTXO.
In combination with other parts of the v3 transaction relay
proposal, it is hoped that this will eliminate all policy-based
concerns about <a href="/en/topics/transaction-pinning/">transaction pinning attacks</a> against time-sensitive contract protocol transactions.</p>
<p>Additionally, because anyone can fee bump a transaction containing
an ephemeral output, it can be used for contract protocols involving
more than two participants. The existing Bitcoin Core carve out
rule only reliably works for two participants and <a href="https://github.com/bitcoin/bitcoin/issues/18725">previous
attempts</a> to increase it required an
arbitrary upper limit on participants.</p>
<p>Sanders’s <a href="https://github.com/bitcoin/bitcoin/issues/26403">implementation</a> of ephemeral anchors
makes it possible to begin testing the idea along with the other v3
transaction relay behaviors previously implemented by that
proposal’s author.</p>
</li>
</ul>
<h2 id="bitcoin-core-pr-review-club">Bitcoin Core PR Review Club</h2>
<p><em>In this monthly section, we summarize a recent <a href="https://bitcoincore.reviews/">Bitcoin Core PR Review Club</a>
meeting, highlighting some of the important questions and answers. Click on a
question below to see a summary of the answer from the meeting.</em></p>
<p><a href="https://bitcoincore.reviews/26152">Bump unconfirmed ancestor transactions to target feerate</a>
is a PR by Xekyo (Murch) and glozow that improves the accuracy of the wallet’s fee
calculation in the case that unconfirmed UTXOs are selected as inputs.
Without the PR, the fee is set too low if the
feerates of some unconfirmed transactions being used as inputs are lower
than that of the transaction being constructed. The PR fixes
this by adding enough fee to “expedite” such low-fee source
transactions to the same feerate as targeted by the new transaction.</p>
<p>Note that even without this PR, the process of coin selection will
try to avoid spending from low-feerate unconfirmed transactions.
This PR will be beneficial in cases where this can’t be avoided.</p>
<p>Adjusting the fee to account for these ancestor transactions turns out
to be similar to choosing which transactions to include
in a block, so this PR adds a class called <code class="highlighter-rouge">MiniMiner</code>.</p>
<p>This PR review <a href="https://bitcoincore.reviews/26152">spanned</a> two <a href="https://bitcoincore.reviews/26152-2">weeks</a>.</p>
<div class="qa_details development">
<ul>
<li>
<details id="what-problem-does-this-pr-address">
<summary><span>What problem does this PR address?</span></summary>
<p>The wallet fee estimation doesn’t take into account that it may also
need to pay for all unconfirmed ancestors with a lower feerate than the target. <a href="https://bitcoincore.reviews/26152#l-30" class="external">➚</a></p>
</details>
</li>
<li>
<details id="what-does-a-transaction-s-cluster-consist-of">
<summary><span>What does a transaction’s “cluster” consist of?</span></summary>
<p>The set of transactions consisting of itself and all
“connected” transactions. This includes all of its ancestors
and descendants, but also siblings and cousins, i.e. children of
parents who may not be ancestors nor descendants of the
given transaction. <a href="https://bitcoincore.reviews/26152#l-72" class="external">➚</a></p>
</details>
</li>
<li>
<details id="this-pr-introduces-miniminer-which-duplicates-some-of-the-actual-miner-s-algorithms-would-it-have-been-better-to-unify-these-two-implementations-through-refactoring">
<summary><span>This PR introduces <code class="highlighter-rouge">MiniMiner</code> which duplicates some of the
actual miner’s algorithms; would it have been better to
unify these two implementations through refactoring?</span></summary>
<p>We only need to operate on a cluster and not the entire mempool,
and don’t need to apply any of the checks that <code class="highlighter-rouge">BlockAssembler</code>
does. It was also suggested to do this calculation without
holding the mempool lock. We’d also need to change the block
assembler to be tracking bump fees rather than building the
block template; the amount of refactoring necessary was
equivalent to rewriting. <a href="https://bitcoincore.reviews/26152#l-94" class="external">➚</a></p>
</details>
</li>
<li>
<details id="why-does-the-miniminer-require-an-entire-cluster-why-can-t-it-just-use-the-union-of-each-transaction-s-ancestor-sets">
<summary><span>Why does the <code class="highlighter-rouge">MiniMiner</code> require an entire cluster? Why can’t it
just use the union of each transaction’s ancestor sets?</span></summary>
<p>Some of the ancestors may already have been paid for by some of
their other descendants; they don’t need to be bumped further.
So we need to include these other descendants in our calculations. <a href="https://bitcoincore.reviews/26152#l-129" class="external">➚</a></p>
</details>
</li>
<li>
<details id="if-transaction-x-has-a-higher-ancestor-feerate-than-independent-transaction-y-is-it-possible-for-a-miner-to-prioritize-y-over-x-that-is-mine-y-before-x">
<summary><span>If transaction X has a higher <em>ancestor feerate</em> than independent
transaction Y, is it possible for a miner to prioritize Y
over X (that is, mine Y before X)?</span></summary>
<p>Yes. If some of Y’s low-feerate ancestors have <em>other</em> decendants that
are high feerate, Y doesn’t need to “pay” for those ancestors.
Y’s ancestor set is updated to exclude those transactions,
which has the effect of increasing Y’s ancestor feerate. <a href="https://bitcoincore.reviews/26152#l-169" class="external">➚</a></p>
</details>
</li>
<li>
<details id="can-calculatebumpfees-overestimate-underestimate-both-or-neither-by-how-much">
<summary><span>Can <code class="highlighter-rouge">CalculateBumpFees()</code> overestimate, underestimate, both, or
neither? By how much?</span></summary>
<p>It will overestimate if two outputs with overlapping ancestry are
chosen, since each bumps its ancestors independently (without taking the shared
ancestry into account). The
participants concluded that it’s not possible for bump fees to be
underestimated. <a href="https://bitcoincore.reviews/26152#l-194" class="external">➚</a></p>
</details>
</li>
<li>
<details id="the-miniminer-is-given-a-list-of-utxos-outpoints-that-the-wallet-might-be-interested-in-spending-given-an-outpoint-what-are-its-five-possible-states">
<summary><span>The <code class="highlighter-rouge">MiniMiner</code> is given a list of UTXOs (outpoints) that the wallet
might be interested in spending. Given an outpoint, what are its five
possible states?</span></summary>
<p>It could be (1) confirmed and unspent, (2) confirmed but already being spent
by an existing transaction in the mempool, (3) unconfirmed (in the
mempool) and unspent, (4) unconfirmed
but already spent by an existing transaction in the mempool,
or (5) it could be an outpoint that we’ve never heard of. <a href="https://bitcoincore.reviews/26152-2#l-21" class="external">➚</a></p>
</details>
</li>
<li>
<details id="what-approach-is-taken-in-the-bump-unconfirmed-parent-txs-to-target-feerate-commit">
<summary><span>What approach is taken in the “Bump unconfirmed parent txs to target
feerate” commit?</span></summary>
<p>This commit is the main behavior change of the PR.
We use the <code class="highlighter-rouge">MiniMiner</code> to calculate the bump fees (the fees needed to bump
their respective ancestries to the target feerate) of each UTXO and
deduct those from their effective values.
Then we run coin selection as before. <a href="https://bitcoincore.reviews/26152-2#l-100" class="external">➚</a></p>
</details>
</li>
<li>
<details id="how-does-the-pr-handle-spending-unconfirmed-utxos-with-overlapping-ancestry">
<summary><span>How does the PR handle spending unconfirmed UTXOs with overlapping ancestry?</span></summary>
<p>After coin selection, we run a variant of the <code class="highlighter-rouge">MiniMiner</code> algorithm
on the <em>result</em> of each coin selection run to get an exact bump fee.
If we have over-bumped due to shared ancestry, we can reduce
the fees by increasing the change value if it exists, or adding a
change output if it doesn’t exist. <a href="https://bitcoincore.reviews/26152-2#l-111" class="external">➚</a></p>
</details>
</li>
</ul>
</div>
<h2 id="releases-and-release-candidates">Releases and release candidates</h2>
<p><em>New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
release candidates.</em></p>
<ul>
<li id="btcpay-server-1-7-1" class="anchor-list">
<p><a href="#btcpay-server-1-7-1" class="anchor-list-link">●</a> <a href="https://github.com/btcpayserver/btcpayserver/releases/tag/v1.7.1">BTCPay Server 1.7.1</a> is the latest release of the most widely used
self-hosted payment processing software for Bitcoin.</p>
</li>
<li id="core-lightning-22-11" class="anchor-list">
<p><a href="#core-lightning-22-11" class="anchor-list-link">●</a> <a href="https://github.com/ElementsProject/lightning/releases/tag/v22.11">Core Lightning 22.11</a> is the next major version of CLN. It’s also
the first release to use a new version numbering scheme.<sup id="fnref:semver"><a href="#fn:semver" class="footnote">1</a></sup>
Included are several new features, including a new plugin manager,
and multiple bug fixes.</p>
</li>
<li id="lnd-0-15-5-beta" class="anchor-list">
<p><a href="#lnd-0-15-5-beta" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/releases/tag/v0.15.5-beta">LND 0.15.5-beta</a> is a maintenance release of LND. It contains
only minor bug fixes according to its release notes.</p>
</li>
<li id="bdk-0-25-0" class="anchor-list">
<p><a href="#bdk-0-25-0" class="anchor-list-link">●</a> <a href="https://github.com/bitcoindevkit/bdk/releases/tag/v0.25.0">BDK 0.25.0</a> is a new release for this library for building wallets.</p>
</li>
</ul>
<h2 id="notable-code-and-documentation-changes">Notable code and documentation changes</h2>
<p><em>Notable changes this week in <a href="https://github.com/bitcoin/bitcoin">Bitcoin Core</a>, <a href="https://github.com/ElementsProject/lightning">Core
Lightning</a>, <a href="https://github.com/ACINQ/eclair">Eclair</a>, <a href="https://github.com/lightningdevkit/rust-lightning">LDK</a>,
<a href="https://github.com/lightningnetwork/lnd/">LND</a>, <a href="https://github.com/bitcoin-core/secp256k1">libsecp256k1</a>, <a href="https://github.com/bitcoin-core/HWI">Hardware Wallet
Interface (HWI)</a>, <a href="https://github.com/rust-bitcoin/rust-bitcoin">Rust Bitcoin</a>, <a href="https://github.com/btcpayserver/btcpayserver/">BTCPay
Server</a>, <a href="https://github.com/bitcoindevkit/bdk">BDK</a>, <a href="https://github.com/bitcoin/bips/">Bitcoin Improvement
Proposals (BIPs)</a>, and <a href="https://github.com/lightning/bolts">Lightning BOLTs</a>.</em></p>
<ul>
<li id="bitcoin-core-19762" class="anchor-list">
<p><a href="#bitcoin-core-19762" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin/bitcoin/issues/19762">Bitcoin Core #19762</a> updates the RPC (and, by extension,
<code class="highlighter-rouge">bitcoin-cli</code>) interface to allow named and positional arguments to be
used together. This change makes it more convenient to use named
parameter values without having to name every one. The PR description
provides examples demonstrating the increased convenience of this
approach as well as a handy shell alias for frequent users of
<code class="highlighter-rouge">bitcoin-cli</code>.</p>
</li>
<li id="core-lightning-5722" class="anchor-list">
<p><a href="#core-lightning-5722" class="anchor-list-link">●</a> <a href="https://github.com/ElementsProject/lightning/issues/5722">Core Lightning #5722</a> adds <a href="https://github.com/cdecker/lightning/blob/20bc743840bf5d948efbf62d32a21a00ed233e31/plugins/grpc-plugin/README.md">documentation</a> about how to
use the GRPC interface plugin.</p>
</li>
<li id="eclair-2513" class="anchor-list">
<p><a href="#eclair-2513" class="anchor-list-link">●</a> <a href="https://github.com/ACINQ/eclair/issues/2513">Eclair #2513</a> updates how it uses the Bitcoin Core wallet to ensure
it always sends change to P2WPKH outputs. This
is the result of <a href="https://github.com/bitcoin/bitcoin/issues/23789">Bitcoin Core #23789</a> (see <a href="/en/newsletters/2022/01/05/#bitcoin-core-23789">Newsletter
#181</a>) where the project addressed a privacy
concern for adopters of new output types (e.g. <a href="/en/topics/taproot/">taproot</a>). Previously, a user who set their wallet default address
type to taproot would also create taproot change outputs when they
paid someone. If they paid someone who didn’t use taproot, it was
easy for third parties to determine which output was the payment (the
non-taproot output) and which was the change output (the taproot
output). After the change to Bitcoin Core, it would default to trying
to use the same type of change output as the paid output, e.g. a
payment to a native segwit output would also result in a native segwit
change output.</p>
<p>However, the LN protocol requires certain output types. For
example, a P2PKH output can’t be used to open an LN channel.
For that reason, users of Eclair with Bitcoin Core need to ensure
they don’t generate change outputs of an LN-incompatible type.</p>
</li>
<li id="rust-bitcoin-1415" class="anchor-list">
<p><a href="#rust-bitcoin-1415" class="anchor-list-link">●</a> <a href="https://github.com/rust-bitcoin/rust-bitcoin/issues/1415">Rust Bitcoin #1415</a> begins using the <a href="https://github.com/model-checking/kani">Kani Rust Verifier</a> to
prove some properties of Rust Bitcoin’s code. This complements other
continuous integration tests performed on the code, such as fuzzing.</p>
</li>
<li id="btcpay-server-4238" class="anchor-list">
<p><a href="#btcpay-server-4238" class="anchor-list-link">●</a> <a href="https://github.com/btcpayserver/btcpayserver/issues/4238">BTCPay Server #4238</a> adds an invoice refund endpoint to BTCPay’s
Greenfield API, a more recent API different from the original BitPay-inspired API.</p>
</li>
</ul>
<h2 id="footnotes">Footnotes</h2>
<div class="footnotes">
<ol>
<li id="fn:semver">
<p>Previous editions of this newsletter claimed Core Lightning used the
<a href="https://semver.org/spec/v2.0.0.html">semantic versioning</a> scheme and new versions would continue using
that scheme in the future. Rusty Russell has <a href="https://github.com/ElementsProject/lightning/issues/5716#issuecomment-1322745630">described</a> why CLN can’t completely adhere to that scheme. We thank
Matt Whitlock for notifying us about our previous error. <a href="#fnref:semver" class="reversefootnote">↩</a></p>
</li>
</ol>
</div>Bitcoin OptechThis week’s newsletter describes an implementation of ephemeral anchors and includes our regular sections with the summary of a Bitcoin Core PR Review Club meeting, announcements of new releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure projects.Bitcoin Optech Newsletter #2282022-11-30T00:00:00+00:002022-11-30T00:00:00+00:00https://bitcoinops.org/en/newsletters/2022/11/2022-11-30-newsletter<p>This week’s newsletter describes a proposal to mitigate LN jamming
attacks using reputation credential tokens. Also included are our
regular sections with announcements of new software releases and release
candidates and summaries of notable changes to popular Bitcoin
infrastructure software.</p>
<h2 id="news">News</h2>
<ul>
<li id="reputation-credentials-proposal-to-mitigate-ln-jamming-attacks" class="anchor-list">
<p><a href="#reputation-credentials-proposal-to-mitigate-ln-jamming-attacks" class="anchor-list-link">●</a> <strong>Reputation credentials proposal to mitigate LN jamming attacks:</strong>
Antoine Riard <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html">posted</a> to the Lightning-Dev mailing
list a <a href="https://github.com/lightning/bolts/blob/80214c83190836c4f7699af9e8920769607f1a00/www-reputation-credentials-protocol.md">proposal</a> for a new credential-based
reputation system to help prevent attackers from temporarily blocking
payment (<a href="/en/topics/htlc/">HTLC</a>) slots or value, preventing honest users
from being able to send payments—a problem called <a href="/en/topics/channel-jamming-attacks/">channel jamming
attacks</a>.</p>
<p>In LN today, spenders choose a path from their node to the receiving
node across multiple channels operated by independent forwarding
nodes. They create a set of trustless instructions that describes
where each forwarding node should next relay the payment, encrypting
those instructions so that each node receives only the minimum
information it needs to do its job.</p>
<p>Riard proposes that each forwarding node should only accept the relay
instructions if they include one or more credential tokens that were
previously issued by that forwarding node. The credentials include
a <a href="https://en.wikipedia.org/wiki/Blind_signature">blind signature</a> that prevents the forwarding node from
directly determining which node was issued the credential
(preventing the forwarding node from learning the network identity
of the spender). Each node may issue credentials according to its
own policy, although Riard suggests several distribution methods:</p>
<ul>
<li id="upfront-payments" class="anchor-list">
<p><a href="#upfront-payments" class="anchor-list-link">●</a> <em>Upfront payments:</em> if Alice’s node wants to forward payments
through Bob’s node, her node first uses LN to buy a credential
from Bob.</p>
</li>
<li id="previous-success" class="anchor-list">
<p><a href="#previous-success" class="anchor-list-link">●</a> <em>Previous success:</em> if a payment that Alice sent through Bob’s
node is successfully accepted by the ultimate receiver, Bob’s node
can return a credential token to Alice’s node—or even more
tokens than were previously used, allowing Alice’s node to send
additional value through Bob’s node in the future.</p>
</li>
<li id="utxo-ownership-proofs-or-other-alternatives" class="anchor-list">
<p><a href="#utxo-ownership-proofs-or-other-alternatives" class="anchor-list-link">●</a> <em>UTXO ownership proofs or other alternatives:</em> although not
necessary for Riard’s initial proposal, some forwarding nodes may
experiment with giving credentials to everyone who proves they own
a Bitcoin UTXO, perhaps with modifiers that give older or
higher-value UTXOs more credential tokens than newer or
lower-value UTXOs. Any other criteria can be used as each
forwarding node chooses for itself how to distribute its
credential tokens.</p>
</li>
</ul>
<p>Clara Shikhelman, whose own co-authored proposal partly based on
local reputation was described in <a href="/en/newsletters/2022/11/16/#paper-about-channel-jamming-attacks">Newsletter #226</a>,
replied to <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003755.html">ask</a> whether credential tokens
were transferable between users and whether that could lead to the
creation of a market for tokens. She also asked how they would work
with <a href="/en/topics/rendez-vous-routing/">blinded paths</a> where a spending node
wouldn’t know the full path to the receiving node.</p>
<p>Riard <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003765.html">replied</a> that it would be difficult to
redistribute credential tokens and create a market for them because
any transfer would require trust. For example, if Bob’s node
issues a new credential to Alice, who then tries to sell the
credential to Carol, there’s no trustless way for Alice to prove she
won’t try to use the token herself even after Carol has paid her.</p>
<p>For blinded paths, <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003767.html">it appears</a> the receiver can
provide any necessary credentials in an encrypted form without
introducing a secondary vulnerability.</p>
<p>Additional feedback for the proposals was received on its related
<a href="https://github.com/lightning/bolts/issues/1043">pull request</a>.</p>
</li>
</ul>
<h2 id="releases-and-release-candidates">Releases and release candidates</h2>
<p><em>New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
release candidates.</em></p>
<ul>
<li id="lnd-0-15-5-beta-rc2" class="anchor-list">
<p><a href="#lnd-0-15-5-beta-rc2" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/releases/tag/v0.15.5-beta.rc2">LND 0.15.5-beta.rc2</a> is a release candidate for a maintenance
release of LND. It contains only minor bug fixes according to its
planned release notes.</p>
</li>
<li id="core-lightning-22-11rc3" class="anchor-list">
<p><a href="#core-lightning-22-11rc3" class="anchor-list-link">●</a> <a href="https://github.com/ElementsProject/lightning/releases/tag/v22.11rc3">Core Lightning 22.11rc3</a> is a release candidate for the next major
version of CLN. It’ll also be the first release to use a new version
numbering scheme, although CLN releases continue to use <a href="https://semver.org/spec/v2.0.0.html">semantic
versioning</a>.</p>
</li>
</ul>
<h2 id="notable-code-and-documentation-changes">Notable code and documentation changes</h2>
<p><em>Notable changes this week in <a href="https://github.com/bitcoin/bitcoin">Bitcoin Core</a>, <a href="https://github.com/ElementsProject/lightning">Core
Lightning</a>, <a href="https://github.com/ACINQ/eclair">Eclair</a>, <a href="https://github.com/lightningdevkit/rust-lightning">LDK</a>,
<a href="https://github.com/lightningnetwork/lnd/">LND</a>, <a href="https://github.com/bitcoin-core/secp256k1">libsecp256k1</a>, <a href="https://github.com/bitcoin-core/HWI">Hardware Wallet
Interface (HWI)</a>, <a href="https://github.com/rust-bitcoin/rust-bitcoin">Rust Bitcoin</a>, <a href="https://github.com/btcpayserver/btcpayserver/">BTCPay
Server</a>, <a href="https://github.com/bitcoindevkit/bdk">BDK</a>, <a href="https://github.com/bitcoin/bips/">Bitcoin Improvement
Proposals (BIPs)</a>, and <a href="https://github.com/lightning/bolts">Lightning BOLTs</a>.</em></p>
<ul>
<li id="core-lightning-5727" class="anchor-list">
<p><a href="#core-lightning-5727" class="anchor-list-link">●</a> <a href="https://github.com/ElementsProject/lightning/issues/5727">Core Lightning #5727</a> begins deprecating numeric JSON request IDs
in favor of IDs using the string type. <a href="https://github.com/rustyrussell/lightning/blob/a25c5d14fe986b67178988e6ebb79610672cc829/doc/lightningd-rpc.7.md#json-ids">Documentation</a>
is added describing the benefit of string IDs and how to get the most
out of creating and interpreting them.</p>
</li>
<li id="eclair-2499" class="anchor-list">
<p><a href="#eclair-2499" class="anchor-list-link">●</a> <a href="https://github.com/ACINQ/eclair/issues/2499">Eclair #2499</a> allows specifying a blinded route to use when using a
<a href="/en/topics/offers/">BOLT12 offer</a> to request payment. The route may
include a route leading up to the user’s node plus additional hops
going past it. The hops going past the node won’t be used, but they
will make it harder for the spender to determine how many hops the
receiver is from the last non-blinded forwarding node in the route.</p>
</li>
<li id="lnd-7122" class="anchor-list">
<p><a href="#lnd-7122" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/issues/7122">LND #7122</a> adds support to <code class="highlighter-rouge">lncli</code> for processing binary <a href="/en/topics/psbt/">PSBT</a> files. <a href="https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki">BIP174</a> specifies that PSBTs may be encoded either as plain
text Base64 or binary in a file. Prior, LND already supported importing
Base64-encoded PSBTs either as plain text or from file.</p>
</li>
<li id="ldk-1852" class="anchor-list">
<p><a href="#ldk-1852" class="anchor-list-link">●</a> <a href="https://github.com/lightningdevkit/rust-lightning/issues/1852">LDK #1852</a> accepts a feerate increase proposed by a channel peer
even if that feerate isn’t high enough to safely keep the channel
open at present. Even if the new feerate isn’t entirely safe, its
higher value means it’s safer than what the node had before, so it’s
better to accept it than try to close the channel with its existing
lower feerate. A future change to LDK may close channels with
feerates that are too low, and work on proposals like <a href="/en/topics/package-relay/">package
relay</a> may make <a href="/en/topics/anchor-outputs/">anchor outputs</a> or similar techniques adaptable enough to eliminate concerns
about present feerates.</p>
</li>
<li id="libsecp256k1-993" class="anchor-list">
<p><a href="#libsecp256k1-993" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin-core/secp256k1/issues/993">Libsecp256k1 #993</a> includes in the default build options the
modules for extrakeys (functions for working with x-only pubkeys),
<a href="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman">ECDH</a>, and <a href="/en/topics/schnorr-signatures/">schnorr signatures</a>. The
module for reconstructing a public key from a signature is still not
built by default “because we don’t recommend ECDSA recovery for new
protocols. In particular, the recovery API is prone to misuse: It
invites the caller to forget to check the public key (and the
verification function always returns 1).”</p>
</li>
</ul>Bitcoin OptechThis week’s newsletter describes a proposal to mitigate LN jamming attacks using reputation credential tokens. Also included are our regular sections with announcements of new software releases and release candidates and summaries of notable changes to popular Bitcoin infrastructure software.Bitcoin Optech Newsletter #2272022-11-23T00:00:00+00:002022-11-23T00:00:00+00:00https://bitcoinops.org/en/newsletters/2022/11/2022-11-23-newsletter<p>This week’s newsletter contains our regular sections with selected
questions and answers from the Bitcoin Stack Exchange, announcements of
new releases and release candidates, and descriptions of notable changes
to popular Bitcoin infrastructure projects.</p>
<h2 id="news">News</h2>
<p><em>No significant news this week was found on the Bitcoin-Dev or
Lightning-Dev mailing lists.</em></p>
<h2 id="selected-qa-from-bitcoin-stack-exchange">Selected Q&A from Bitcoin Stack Exchange</h2>
<p><em><a href="https://bitcoin.stackexchange.com/">Bitcoin Stack Exchange</a> is one of the first places Optech
contributors look for answers to their questions—or when we have a
few spare moments to help curious or confused users. In
this monthly feature, we highlight some of the top-voted questions and
answers posted since our last update.</em></p>
<ul>
<li id="did-the-p2sh-bip-0016-make-some-bitcoin-unspendable" class="anchor-list">
<p><a href="#did-the-p2sh-bip-0016-make-some-bitcoin-unspendable" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/115803">Did the P2SH BIP-0016 make some Bitcoin unspendable?</a>
User bca-0353f40e lists 6 outputs that existed with the P2SH script format,
<code class="highlighter-rouge">OP_HASH160 OP_DATA_20 [hash_value] OP_EQUAL</code>, before <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki">BIP16</a>’s activation.
One of those outputs had been spent under the old rules before activation and
an <a href="https://github.com/bitcoin/bitcoin/commit/ce650182f4d9847423202789856e6e5f499151f8">exception made</a> for that single block in the
P2SH activation code. Other than this exception, activation applied back to
the genesis block so the remaining UTXOs would need to satisfy BIP16 rules in
order to be spent.</p>
</li>
<li id="what-software-was-used-to-make-p2pk-transactions" class="anchor-list">
<p><a href="#what-software-was-used-to-make-p2pk-transactions" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/115962">What software was used to make P2PK transactions?</a>
Pieter Wuille notes that P2PK outputs were created using the original Bitcoin
software in coinbase transactions as well as when sending using <a href="https://en.bitcoin.it/wiki/IP_transaction">pay-to-IP
address</a>.</p>
</li>
<li id="why-are-both-txid-and-wtxid-sent-to-peers" class="anchor-list">
<p><a href="#why-are-both-txid-and-wtxid-sent-to-peers" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/115907">Why are both txid and wtxid sent to peers?</a>
Pieter Wuille references <a href="https://github.com/bitcoin/bips/blob/master/bip-0339.mediawiki">BIP339</a> and explains that while using wtxid is
better for relay (due to malleability among other reasons), some peers do not
support the newer wtxid identifiers and txids are supported for older
pre-BIP339 peers for backward compatibility.</p>
</li>
<li id="how-do-i-create-a-taproot-multisig-address" class="anchor-list">
<p><a href="#how-do-i-create-a-taproot-multisig-address" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/115700">How do I create a taproot multisig address?</a>
Pieter Wuille points out that Bitcoin Core’s existing <a href="/en/topics/multisignature/">multisig</a> RPCs (like
<code class="highlighter-rouge">createmultisig</code> and <code class="highlighter-rouge">addmultisigaddress</code>) will only support legacy wallets
and outlines that with Bitcoin Core 24.0, users will be able to use
<a href="/en/topics/output-script-descriptors/">descriptors</a> and RPCs (like <code class="highlighter-rouge">deriveaddresses</code> and
<code class="highlighter-rouge">importdescriptors</code>) along with the new <code class="highlighter-rouge">multi_a</code> descriptor to create
<a href="/en/topics/taproot/">taproot</a>-compatible multisig scripts.</p>
</li>
<li id="is-it-possible-to-skip-initial-block-download-ibd-on-pruned-node" class="anchor-list">
<p><a href="#is-it-possible-to-skip-initial-block-download-ibd-on-pruned-node" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/116030">Is it possible to skip Initial Block Download (IBD) on pruned node?</a>
While not currently supported in Bitcoin Core, Pieter Wuille points to the
<a href="/en/topics/assumeutxo/">assumeutxo</a> project which would allow for a new node to
bootstrap by fetching a UTXO set that can be verified by a hard-coded hash.</p>
</li>
</ul>
<h2 id="releases-and-release-candidates">Releases and release candidates</h2>
<p><em>New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
release candidates.</em></p>
<ul>
<li id="lnd-0-15-5-beta-rc2" class="anchor-list">
<p><a href="#lnd-0-15-5-beta-rc2" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/releases/tag/v0.15.5-beta.rc2">LND 0.15.5-beta.rc2</a> is a release candidate for a maintenance
release of LND. It contains only minor bug fixes according to its
planned release notes.</p>
</li>
<li id="core-lightning-22-11rc2" class="anchor-list">
<p><a href="#core-lightning-22-11rc2" class="anchor-list-link">●</a> <a href="https://github.com/ElementsProject/lightning/releases/tag/v22.11rc2">Core Lightning 22.11rc2</a> is a release candidate for the next major
version of CLN. It’ll also be the first release to use a new version
numbering scheme, although CLN releases continue to use <a href="https://semver.org/spec/v2.0.0.html">semantic
versioning</a>.</p>
</li>
</ul>
<h2 id="notable-code-and-documentation-changes">Notable code and documentation changes</h2>
<p><em>Notable changes this week in <a href="https://github.com/bitcoin/bitcoin">Bitcoin Core</a>, <a href="https://github.com/ElementsProject/lightning">Core
Lightning</a>, <a href="https://github.com/ACINQ/eclair">Eclair</a>, <a href="https://github.com/lightningdevkit/rust-lightning">LDK</a>,
<a href="https://github.com/lightningnetwork/lnd/">LND</a>, <a href="https://github.com/bitcoin-core/secp256k1">libsecp256k1</a>, <a href="https://github.com/bitcoin-core/HWI">Hardware Wallet
Interface (HWI)</a>, <a href="https://github.com/rust-bitcoin/rust-bitcoin">Rust Bitcoin</a>, <a href="https://github.com/btcpayserver/btcpayserver/">BTCPay
Server</a>, <a href="https://github.com/bitcoindevkit/bdk">BDK</a>, <a href="https://github.com/bitcoin/bips/">Bitcoin Improvement
Proposals (BIPs)</a>, and <a href="https://github.com/lightning/bolts">Lightning BOLTs</a>.</em></p>
<ul>
<li id="bitcoin-core-25730" class="anchor-list">
<p><a href="#bitcoin-core-25730" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin/bitcoin/issues/25730">Bitcoin Core #25730</a> updates the <code class="highlighter-rouge">listunspent</code> RPC with a new
argument that will include in the results any immature coinbase
outputs—outputs which can’t yet be spent because fewer than 100
blocks have passed since they were included in the miner coinbase
transaction of a block.</p>
</li>
<li id="lnd-7082" class="anchor-list">
<p><a href="#lnd-7082" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/issues/7082">LND #7082</a> updates the way invoices without requested amounts are
created to allow the inclusion of route hints, which can help the spender find
a path to the receiver.</p>
</li>
<li id="ldk-1413" class="anchor-list">
<p><a href="#ldk-1413" class="anchor-list-link">●</a> <a href="https://github.com/lightningdevkit/rust-lightning/issues/1413">LDK #1413</a> removes support for the original fixed-length onion data
format. The upgraded variable-length format was added to the
specification over three years ago and support for the old version has
already been removed from the specification (see <a href="/en/newsletters/2022/10/05/#bolts-962">Newsletter
#220</a>), Core Lightning (<a href="/en/newsletters/2022/03/30/#c-lightning-5058">Newsletter #193</a>), LND (<a href="/en/newsletters/2022/04/20/#lnd-6385">Newsletter #196</a>), and Eclair
(<a href="/en/newsletters/2022/09/14/#eclair-2190">Newsletter #217</a>).</p>
</li>
<li id="hwi-637" class="anchor-list">
<p><a href="#hwi-637" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin-core/HWI/issues/637">HWI #637</a> adds support for a major planned upgrade of the
Bitcoin-related firmware for Ledger devices. Not included in this PR
but mentioned in its description as future planned work is the policy
management work mentioned in <a href="/en/newsletters/2022/05/18/#adapting-miniscript-and-output-script-descriptors-for-hardware-signing-devices">Newsletter #200</a>.</p>
</li>
</ul>Bitcoin OptechThis week’s newsletter contains our regular sections with selected questions and answers from the Bitcoin Stack Exchange, announcements of new releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure projects.Bitcoin Optech Newsletter #2262022-11-16T00:00:00+00:002022-11-16T00:00:00+00:00https://bitcoinops.org/en/newsletters/2022/11/2022-11-16-newsletter<p>This week’s newsletter describes a proposal to enable generalized smart
contracts on Bitcoin and summarizes a paper about addressing LN channel
jamming attacks. Also included are our regular sections with
descriptions of changes to services and client software, announcements
of new releases and release candidates, and summaries of notable changes
to popular Bitcoin infrastructure software.</p>
<h2 id="news">News</h2>
<ul>
<li id="general-smart-contracts-in-bitcoin-via-covenants" class="anchor-list">
<p><a href="#general-smart-contracts-in-bitcoin-via-covenants" class="anchor-list-link">●</a> <strong>General smart contracts in Bitcoin via covenants:</strong> Salvatore Ingala
<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html">posted</a> to the Bitcoin-Dev mailing list a proposal for a
new type of <a href="/en/topics/covenants/">covenant</a> (requiring a soft fork) that
would allow using <a href="https://en.wikipedia.org/wiki/Merkle_tree">merkle trees</a> to create smart contracts that can
carry state from one onchain transaction to another. To use an
example from Ingala’s post, two users could wager on a game of chess
where the contract could hold the rules of the game and the state
could hold the positions of all the pieces on the board, with it being
possible to update that state by each onchain transaction. Of course,
a well-designed contract would allow the game to be played offchain
with only the settlement transaction at the end of the game being put
onchain (or possibly even then staying offchain if the game was played
within another offchain construct, such as a payment channel).</p>
<p>Ingala explains how the work could help design <a href="/en/topics/joinpools/">joinpools</a>, optimistic rollups (see <a href="/en/newsletters/2022/10/19/#validity-rollups-research">Newsletter #222</a>), and other stateful constructions.</p>
</li>
<li id="paper-about-channel-jamming-attacks" class="anchor-list">
<p><a href="#paper-about-channel-jamming-attacks" class="anchor-list-link">●</a> <strong>Paper about channel jamming attacks:</strong> Clara Shikhelman and Sergei
Tikhomirov <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003740.html">posted</a> to the Lightning-Dev mailing list
the summary of a <a href="https://raw.githubusercontent.com/s-tikhomirov/ln-jamming-simulator/master/unjamming-lightning.pdf">paper</a> they’ve written about
solutions to <a href="/en/topics/channel-jamming-attacks/">channel jamming attacks</a>.
These attacks, first described in 2015, can make large numbers of
channels unusable for long periods of time at negligible cost to an
attacker.</p>
<p>The authors split jamming attacks into two types. The first is <em>slow
jamming</em> where a channel’s limited slots or funds for payment
forwarding are made unavailable for long periods of time—which
rarely happens with legitimate payments. The second type is <em>fast
jamming</em> where the slots and funds are blocked only briefly—which
happens often with normal payments, potentially making fast jamming
harder to mitigate.</p>
<p>They suggest two solutions:</p>
<ul>
<li id="unconditional-fees" class="anchor-list">
<p><a href="#unconditional-fees" class="anchor-list-link">●</a> <em>Unconditional fees</em> (the same as <em>upfront fees</em> described in
previous newsletters), where some amount of fee is paid to
forwarding nodes even if a payment fails to reach the receiver.
The authors suggest both a <em>base</em> upfront fee that’s independent
of the amount of the payment and a <em>proportional</em> fee that
increases with the payment amount. The two separate fees
respectively address HTLC slot jamming and liquidity jamming. The
fees can be very small because they’re only meant to prevent fast
jamming, which requires frequent resends of fake payments that
would each need to pay additional upfront fees, raising the cost
for the attacker.</p>
</li>
<li id="local-reputation-with-forwarding" class="anchor-list">
<p><a href="#local-reputation-with-forwarding" class="anchor-list-link">●</a> <em>Local reputation with forwarding,</em> where each node would keep
statistics about each of its peers related to how long its
forwarded payments remain pending and the forwarding fees
collected. If a peer’s time per fee is high, it considers that
peer high-risk and only allows that peer to use a limited number
of the local node’s slots and funds. Otherwise, it considers the
peer low-risk.</p>
<p>When a node receives a forwarded payment from a peer it considers
low-risk, it checks to see whether that peer tagged the
payment as also being low-risk. If both the upstream forwarding
node and the payment are low-risk, it allows the payment to use
any available slot and funds.</p>
</li>
</ul>
<p>The paper received some discussion on the mailing list, with the
proposed local reputation method specifically being praised.</p>
</li>
</ul>
<h2 id="changes-to-services-and-client-software">Changes to services and client software</h2>
<p><em>In this monthly feature, we highlight interesting updates to Bitcoin
wallets and services.</em></p>
<ul>
<li id="sparrow-1-7-0-released" class="anchor-list">
<p><a href="#sparrow-1-7-0-released" class="anchor-list-link">●</a> <strong>Sparrow 1.7.0 released:</strong>
<a href="https://github.com/sparrowwallet/sparrow/releases/tag/1.7.0">Sparrow 1.7.0</a> adds support for a <a href="/en/topics/replace-by-fee/">Replace-By-Fee (RBF)</a>-enabled
transaction cancellation feature among other updates.</p>
</li>
<li id="blixt-wallet-adds-taproot-support" class="anchor-list">
<p><a href="#blixt-wallet-adds-taproot-support" class="anchor-list-link">●</a> <strong>Blixt Wallet adds taproot support:</strong>
<a href="https://github.com/hsjoberg/blixt-wallet/releases/tag/v0.6.0">Blixt Wallet v0.6.0</a> adds send and receive support for <a href="/en/topics/taproot/">taproot</a> addresses.</p>
</li>
<li id="specter-diy-v1-8-0-released" class="anchor-list">
<p><a href="#specter-diy-v1-8-0-released" class="anchor-list-link">●</a> <strong>Specter-DIY v1.8.0 released:</strong>
<a href="https://github.com/cryptoadvance/specter-diy/releases/tag/v1.8.0">Specter-DIY v1.8.0</a> now supports <a href="/en/topics/reproducible-builds/">reproducible builds</a> and <a href="/en/topics/taproot/">taproot</a> keypath spending support.</p>
</li>
<li id="trezor-suite-adds-coin-control-features" class="anchor-list">
<p><a href="#trezor-suite-adds-coin-control-features" class="anchor-list-link">●</a> <strong>Trezor Suite adds coin control features:</strong>
In a <a href="https://blog.trezor.io/coin-control-in-trezor-suite-92f3455fd706">recent blog post</a>, Trezor announced that Trezor
Suite now supports <a href="/en/topics/coin-selection/">coin control</a> features.</p>
</li>
<li id="strike-adds-taproot-send-support" class="anchor-list">
<p><a href="#strike-adds-taproot-send-support" class="anchor-list-link">●</a> <strong>Strike adds taproot send support:</strong>
Strike’s wallet now allows sending to <a href="/en/topics/bech32/">bech32m</a> addresses.</p>
</li>
<li id="kollider-exchange-launches-with-lightning-support" class="anchor-list">
<p><a href="#kollider-exchange-launches-with-lightning-support" class="anchor-list-link">●</a> <strong>Kollider exchange launches with Lightning support:</strong>
Kollider <a href="https://blog.kollider.xyz/announcing-kolliders-launch/">announced</a> an exchange with LN deposit and
withdrawal capabilities as well as a browser-based Lightning wallet.</p>
</li>
</ul>
<h2 id="releases-and-release-candidates">Releases and release candidates</h2>
<p><em>New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
release candidates.</em></p>
<ul>
<li id="bitcoin-core-24-0-rc4" class="anchor-list">
<p><a href="#bitcoin-core-24-0-rc4" class="anchor-list-link">●</a> <a href="https://bitcoincore.org/bin/bitcoin-core-24.0/">Bitcoin Core 24.0 RC4</a> is a release candidate for the
next version of the network’s most widely used full node
implementation. A <a href="https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Candidate-Testing-Guide">guide to testing</a> is available.</p>
<p><strong>Warning:</strong> this release candidate includes the <code class="highlighter-rouge">mempoolfullrbf</code>
configuration option which several protocol and application developers
believe could lead to problems for merchant services as described in
previous newsletters <a href="/en/newsletters/2022/10/19/#transaction-replacement-option">#222</a> and <a href="/en/newsletters/2022/10/26/#continued-discussion-about-full-rbf">#223</a>. It
could also cause problems for transaction relay as described in
<a href="/en/newsletters/2022/11/02/#mempool-consistency">Newsletter #224</a>.</p>
</li>
<li id="lnd-0-15-5-beta-rc1" class="anchor-list">
<p><a href="#lnd-0-15-5-beta-rc1" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/releases/tag/v0.15.5-beta.rc1">LND 0.15.5-beta.rc1</a> is a release candidate for a maintenance
release of LND. It’s contains only minor bug fixes according to its
planned release notes.</p>
</li>
</ul>
<h2 id="notable-code-and-documentation-changes">Notable code and documentation changes</h2>
<p><em>Notable changes this week in <a href="https://github.com/bitcoin/bitcoin">Bitcoin Core</a>, <a href="https://github.com/ElementsProject/lightning">Core
Lightning</a>, <a href="https://github.com/ACINQ/eclair">Eclair</a>, <a href="https://github.com/lightningdevkit/rust-lightning">LDK</a>,
<a href="https://github.com/lightningnetwork/lnd/">LND</a>, <a href="https://github.com/bitcoin-core/secp256k1">libsecp256k1</a>, <a href="https://github.com/bitcoin-core/HWI">Hardware Wallet
Interface (HWI)</a>, <a href="https://github.com/rust-bitcoin/rust-bitcoin">Rust Bitcoin</a>, <a href="https://github.com/btcpayserver/btcpayserver/">BTCPay
Server</a>, <a href="https://github.com/bitcoindevkit/bdk">BDK</a>, <a href="https://github.com/bitcoin/bips/">Bitcoin Improvement
Proposals (BIPs)</a>, and <a href="https://github.com/lightning/bolts">Lightning BOLTs</a>.</em></p>
<ul>
<li id="core-lightning-5681" class="anchor-list">
<p><a href="#core-lightning-5681" class="anchor-list-link">●</a> <a href="https://github.com/ElementsProject/lightning/issues/5681">Core Lightning #5681</a> adds the ability to filter the JSON output of
an RPC on the server side. Filtering on the server side avoids
sending unwanted data when using a bandwidth-constrained remote
connection. In the future, some RPCs may be able to avoid computing
filtered data, allowing them to return sooner. Filtering is not
guaranteed for all RPCs, especially those provided by plugins. When
filtering is not available, the unfiltered full output will be
returned. For more information, see the added <a href="https://github.com/rustyrussell/lightning/blob/a6f38a2c1a47c5497178c199691047320f2c55bc/doc/lightningd-rpc.7.md#field-filtering">documentation</a>.</p>
</li>
<li id="core-lightning-5698" class="anchor-list">
<p><a href="#core-lightning-5698" class="anchor-list-link">●</a> <a href="https://github.com/ElementsProject/lightning/issues/5698">Core Lightning #5698</a> updates the experimental developer mode to
allow receiving onion-wrapped error messages of any size. BOLT2
currently recommends 256-byte errors, but it doesn’t forbid longer error
messages and <a href="https://github.com/lightning/bolts/issues/1021">BOLTs #1021</a> is open to encourage use of 1024-byte
error messages encoded using LN’s modern Type-Length-Value (TLV)
semantics.</p>
</li>
<li id="core-lightning-5647" class="anchor-list">
<p><a href="#core-lightning-5647" class="anchor-list-link">●</a> <a href="https://github.com/ElementsProject/lightning/issues/5647">Core Lightning #5647</a> adds the reckless plugin manager. The plugin manager
may be used to install CLN plugins by name from the <code class="highlighter-rouge">lightningd/plugins</code>
repository. The plugin manager automatically installs dependencies and verifies the
installation. It can also be used to enable and disable plugins as well as
persist the plugin state in a configuration file.</p>
</li>
<li id="ldk-1796" class="anchor-list">
<p><a href="#ldk-1796" class="anchor-list-link">●</a> <a href="https://github.com/lightningdevkit/rust-lightning/issues/1796">LDK #1796</a> updates <code class="highlighter-rouge">Confirm::get_relevant_txids()</code> to return not
just txids but also the hashes of the blocks containing those
referenced transactions. This makes it easier for a higher-level
application to determine when a block chain reorganization may have
changed the confirmation depth of a transaction. If the block hash
for a given txid changes, then a reorganization has occurred.</p>
</li>
<li id="bolts-1031" class="anchor-list">
<p><a href="#bolts-1031" class="anchor-list-link">●</a> <a href="https://github.com/lightning/bolts/issues/1031">BOLTs #1031</a> allows a spender to pay a receiver slightly more than
the requested amount when using <a href="/en/topics/multipath-payments/">simplified multipath payments</a>. This may be required in the case where the
chosen payment paths use channels with a minimum routable amount. For
example, Alice wants to split a 900 sat total into two parts, but both
of the paths she chooses require 500 sat minimum amounts. With this
specification change, she can now send two 500 sat payments, choosing
to overpay by a total of 100 sats in order to use her preferred route.</p>
</li>
</ul>Bitcoin OptechThis week’s newsletter describes a proposal to enable generalized smart contracts on Bitcoin and summarizes a paper about addressing LN channel jamming attacks. Also included are our regular sections with descriptions of changes to services and client software, announcements of new releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.Bitcoin Optech Newsletter #2252022-11-09T00:00:00+00:002022-11-09T00:00:00+00:00https://bitcoinops.org/en/newsletters/2022/11/2022-11-09-newsletter<p>This week’s newsletter summarizes continued discussion about a configuration option for enabling
full-RBF in Bitcoin Core and describes a bug affecting BTCD, LND, and
other software. Also included are our regular sections with the summary
of a Bitcoin Core PR Review Club meeting, descriptions of new releases
and release candidates, and overviews of notable changes to popular
Bitcoin infrastructure software.</p>
<h2 id="news">News</h2>
<ul>
<li id="continued-discussion-about-enabling-full-rbf" class="anchor-list">
<p><a href="#continued-discussion-about-enabling-full-rbf" class="anchor-list-link">●</a> <strong>Continued discussion about enabling full-RBF:</strong> as mentioned in
newsletters for the past several weeks—users, service providers, and
Bitcoin Core developers have been evaluating the inclusion of the
<code class="highlighter-rouge">mempoolfullrbf</code> configuration option into Bitcoin Core’s development
branch and current release candidates for version 24.0. Those
previous newsletters have summarized many previous
arguments for and against this <a href="/en/topics/replace-by-fee/">full RBF</a> option
(<a href="/en/newsletters/2022/10/19/#transaction-replacement-option">1</a>, <a href="/en/newsletters/2022/10/26/#continued-discussion-about-full-rbf">2</a>, <a href="/en/newsletters/2022/11/02/#mempool-consistency">3</a>). This week,
Suhas Daftuar <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html">posted</a> to the Bitcoin-Dev mailing list to
“argue that we should continue to maintain a relay policy where
replacements are rejected for transactions that don’t opt-in to RBF
(as described in BIP 125), and moreover, that we should remove the
<code class="highlighter-rouge">-mempoolfullrbf</code> flag from Bitcoin Core’s latest release candidate
and not plan to release software with that flag, unless (or until)
circumstances change on the network.” He notes:</p>
<ul>
<li id="opt-in-rbf-already-available" class="anchor-list">
<p><a href="#opt-in-rbf-already-available" class="anchor-list-link">●</a> <em>Opt-in RBF already available:</em> anyone who wants the benefits of
RBF should be able to opt-in to it using the mechanism described in
<a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki">BIP125</a>. Users would only be served by full RBF if there was
some reason they couldn’t use opt-in RBF.</p>
</li>
<li id="full-rbf-doesn-t-fix-anything-that-isn-t-broken-in-other-ways" class="anchor-list">
<p><a href="#full-rbf-doesn-t-fix-anything-that-isn-t-broken-in-other-ways" class="anchor-list-link">●</a> <em>Full RBF doesn’t fix anything that isn’t broken in other ways:</em>
a possible case where some users of a multiparty protocol could
deny other users the ability to use opt-in RBF was previously
<a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html">identified</a>, but Daftuar notes that protocol
is vulnerable to other cheap or free attacks which full RBF would
not solve.</p>
</li>
<li id="full-rbf-takes-away-options" class="anchor-list">
<p><a href="#full-rbf-takes-away-options" class="anchor-list-link">●</a> <em>Full RBF takes away options:</em> “absent any other examples [of
problems fixed by fullrbf], it does not seem to me that fullrbf
solves any problems for RBF users, who are already free to choose
to subject their transactions to BIP 125’s RBF policy. From this
perspective, “enabling fullrbf” is really just taking away user
choice to opt a transaction into a non-replacement policy regime.”</p>
</li>
<li id="offering-non-replacement-doesn-t-introduce-any-issues-for-full-nodes" class="anchor-list">
<p><a href="#offering-non-replacement-doesn-t-introduce-any-issues-for-full-nodes" class="anchor-list-link">●</a> <em>Offering non-replacement doesn’t introduce any issues for full nodes:</em>
indeed, it simplifies the handling of long chains of transactions.</p>
</li>
<li id="determining-incentive-compatibility-isn-t-always-straightforward" class="anchor-list">
<p><a href="#determining-incentive-compatibility-isn-t-always-straightforward" class="anchor-list-link">●</a> <em>Determining incentive compatibility isn’t always straightforward:</em>
Daftuar uses the proposal for v3 transaction relay (see
<a href="/en/newsletters/2022/10/05/#proposed-new-transaction-relay-policies-designed-for-ln-penalty">Newsletter #220</a>) as an example:</p>
<blockquote>
<p>Suppose in a few years someone proposes that we add a
“-disable_v3_transaction_enforcement” flag to our software, to
let users decide to turn off those policy restrictions and
treat v3 transactions the same as v2, for all the same reasons
that could be argued today with fullrbf […]</p>
<p>[That] would be subversive to making the lightning use case for
v3 transactions work […] we should not enable users to
disable this policy, because as long as that policy is just
optional and working for those who want it, it shouldn’t harm
anyone that we offer a tighter set of rules for a particular
use case. Adding a way to bypass those rules is just trying to
break someone else’s use case, not trying to add a new one. We
should not wield “incentive compatibility” as a bludgeon for
breaking things that appear to be working and not causing
others harm.</p>
<p>I think this is exactly what is happening with fullrbf.</p>
</blockquote>
</li>
</ul>
<p>Daftuar ends his email with three questions for those who still want
the <code class="highlighter-rouge">mempoolfullrbf</code> option to be included in Bitcoin Core:</p>
<ol>
<li>
<p>“Does fullrbf offer any benefits other than breaking zeroconf
business practices? If so, what are they?”</p>
</li>
<li>
<p>“Is it reasonable to enforce BIP 125’s rbf rules on all
transactions, if those rules themselves are not always incentive
compatible?”</p>
</li>
<li>
<p>“If someone were to propose a command line option that breaks v3
transaction relay in the future, is there a logical basis for
opposing that which is consistent with moving towards fullrbf
now?”</p>
</li>
</ol>
<p>As of this writing, no one has answered Daftuar’s questions on the
mailing list, although two answers to the set of questions were
posted to a Bitcoin Core <a href="https://github.com/bitcoin/bitcoin/issues/26438">PR</a> that Daftuar
opened to propose removing the <code class="highlighter-rouge">mempoolfullrbf</code> configuration
option. Daftuar later <a href="https://github.com/bitcoin/bitcoin/pull/26438#issuecomment-1307715677">closed</a> the PR.</p>
<p>It wasn’t clear at the time of writing whether anyone would comment
further on the topic.</p>
</li>
<li id="block-parsing-bug-affecting-multiple-software" class="anchor-list">
<p><a href="#block-parsing-bug-affecting-multiple-software" class="anchor-list-link">●</a> <strong>Block parsing bug affecting multiple software:</strong> as reported in
<a href="/en/newsletters/2022/10/19/#block-parsing-bug-affecting-btcd-and-lnd">Newsletter #222</a>, it appeared that a serious bug
affecting the BTCD full node and LND LN node was accidentally
triggered, putting users of the software at risk. Updated software
was quickly released. Shortly after that bug was triggered, Anthony
Towns <a href="https://twitter.com/roasbeef/status/1587481219981508608">discovered</a> a second related bug that could only be
triggered by miners. Towns reported the bug to BTCD and LND lead
maintainer Olaoluwa Osuntokun, who prepared a patch to include in the
next general update of the software. Including the security fix
alongside other changes could hide that a vulnerability was being
fixed and reduce the chance of it being exploited. Both Towns and
Osuntokun responsibly kept the vulnerability private until its fix
could be deployed.</p>
<p>Unfortunately, the second related bug was independently rediscovered by
someone who found a miner to trigger it. This new bug
affected BTCD and LND again, but it also affected at least <a href="https://twitter.com/Liquid_BTC/status/1587499305664913413">two
other</a> significant projects or
services. All users of affected systems should upgrade immediately.
We repeat our advice from three weeks ago for anyone using any
Bitcoin software to sign up for security announcements from that
software’s development team.</p>
<p>With the release of this newsletter, Optech has also added a special
topic page where we list the names of <a href="/en/topics/responsible-disclosures/">the amazing people who
responsibly disclosed a vulnerability</a> that we’ve summarized in an Optech newsletter.
There are likely several other disclosures not listed because they
haven’t been made public yet.
We of course also thank all the reviewers of proposals and
pull requests whose diligent effort prevented innumerable
security bugs from making it into released software.</p>
</li>
</ul>
<h2 id="bitcoin-core-pr-review-club">Bitcoin Core PR Review Club</h2>
<p><em>In this monthly section, we summarize a recent <a href="https://bitcoincore.reviews/">Bitcoin Core PR Review Club</a>
meeting, highlighting some of the important questions and answers. Click on a
question below to see a summary of the answer from the meeting.</em></p>
<p><a href="https://bitcoincore.reviews/26265">Relax MIN_STANDARD_TX_NONWITNESS_SIZE to 65 non-witness bytes</a>
is a PR by instagibbs that relaxes the mempool policy’s non-witness transaction size
constraints. It allows transactions to be as small as 65 bytes, replacing
the current policy that requires transactions to be at least 85 bytes (see
<a href="/en/newsletters/2022/10/19/#minimum-relayable-transaction-size">Newsletter #222</a>).</p>
<p>Since this Review Club meeting, this PR has been closed in favor of
PR <a href="https://github.com/bitcoin/bitcoin/issues/26398">#26398</a>, which
relaxes policy even further by disallowing <em>only</em> 64-byte transactions.
The relative merits of these two slightly-different policies were
discussed during the meeting.</p>
<div class="qa_details development">
<ul>
<li>
<details id="why-was-the-minimum-transaction-size-82-bytes-can-you-describe-the-attack">
<summary><span>Why was the minimum transaction size 82 bytes?
Can you describe the attack?</span></summary>
<p>The 82-byte minimum, which was introduced by PR <a href="https://github.com/bitcoin/bitcoin/issues/11423">#11423</a> in 2018, is
the size of the smallest standard payment transaction. This was
presented as a cleanup of the standardness rules. But in reality,
the change was to prevent a 64-byte transaction from being considered standard,
because this size allowed a <a href="/en/topics/cve/#CVE-2017-12842">spoof payment attack</a>
against SPV clients (making them think they’ve received a payment when they hadn’t).
The attack involves tricking an SPV client into thinking that a 64-byte
transaction is an inner node of the transaction merkle tree, which is also
64 bytes in length. <a href="https://bitcoincore.reviews/26265#l-35" class="external">➚</a></p>
</details>
</li>
<li>
<details id="a-participant-asked-was-it-was-necessary-to-fix-this-vulnerability-covertly-given-that-it-would-be-very-expensive-on-the-order-of-usd-1m-to-carry-out-this-attack-combined-with-the-fact-that-it-seems-unlikely-people-would-use-spv-clients-for-payments-that-large">
<summary><span>A participant asked, was it was necessary to fix this vulnerability
covertly, given that it would be very expensive (on the order of USD$1M) to
carry out this attack, combined with the fact that it seems unlikely
people would use SPV clients for payments that large?</span></summary>
<p>There was some agreement, but one participant pointed out that our
intuition about this could be wrong. <a href="https://bitcoincore.reviews/26265#l-66" class="external">➚</a></p>
</details>
</li>
<li>
<details id="what-does-non-witness-size-mean-and-why-do-we-care-about-the-non-witness-distinction">
<summary><span>What does <em>non-witness size</em> mean,
and why do we care about the non-witness distinction?</span></summary>
<p>We care about the non-witness distinction because, as part of the
segwit upgrade, witness data is excluded from the calculation of the merkle root.
Since the attack requires the malicious transaction to be 64 bytes in the
merkle root construction (so it looks like an inner node), we need to exclude
witness data from it. <a href="https://bitcoincore.reviews/26265#l-62" class="external">➚</a></p>
</details>
</li>
<li>
<details id="why-does-setting-this-policy-help-to-prevent-the-attack">
<summary><span>Why does setting this policy help to prevent the attack?</span></summary>
<p>Since inner merkle tree nodes can only be exactly 64 bytes, a transaction
of a different size cannot be misinterpreted as an inner merkle node. <a href="https://bitcoincore.reviews/26265#l-84" class="external">➚</a></p>
</details>
</li>
<li>
<details id="does-it-eliminate-the-attack-vector-entirely">
<summary><span>Does it eliminate the attack vector entirely?</span></summary>
<p>Changing the standardness rules only prevents 64-byte transactions
from being accepted into mempools and relayed, but such transactions
may still be consensus-valid and so can be mined into a block.
For this reason, the attack is still possible, but only with the help of miners. <a href="https://bitcoincore.reviews/26265#l-84" class="external">➚</a></p>
</details>
</li>
<li>
<details id="why-might-we-want-to-change-the-minimum-transaction-size-to-65-bytes-apart-from-the-fact-that-it-s-unnecessary-to-obfuscate-the-cve">
<summary><span>Why might we want to change the minimum transaction size to 65 bytes,
apart from the fact that it’s unnecessary to obfuscate the CVE?</span></summary>
<p>There are legitimate use cases for transactions that are less than 82 bytes.
One example mentioned is a <a href="/en/topics/cpfp/">Child Pays For Parent (CPFP)</a> transaction that assigns
an entire parent output to fees (such a transaction would have a single input
and an empty <code class="highlighter-rouge">OP_RETURN</code> output). <a href="https://bitcoincore.reviews/26265#l-100" class="external">➚</a></p>
</details>
</li>
<li>
<details id="between-disallowing-sizes-less-than-65-bytes-and-sizes-equal-to-64-bytes-which-approach-do-you-think-is-better-and-why-what-are-the-implications-of-both-approaches">
<summary><span>Between disallowing sizes less than 65 bytes and sizes equal to 64 bytes,
which approach do you think is better and why?
What are the implications of both approaches?</span></summary>
<p>After some byte-counting discussion, it was agreed that a valid
but non-standard transaction can be as small as 60 bytes:
a stripped (non-witness) with a single native segwit input is
41 B + 10 B header + 8 B value + 1 B <code class="highlighter-rouge">OP_TRUE</code> or <code class="highlighter-rouge">OP_RETURN</code> = 60 B. <a href="https://bitcoincore.reviews/26265#l-124" class="external">➚</a></p>
</details>
</li>
</ul>
</div>
<h2 id="releases-and-release-candidates">Releases and release candidates</h2>
<p><em>New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
release candidates.</em></p>
<ul>
<li id="rust-bitcoin-0-28-2" class="anchor-list">
<p><a href="#rust-bitcoin-0-28-2" class="anchor-list-link">●</a> <a href="https://github.com/rust-bitcoin/rust-bitcoin/releases/tag/0.28.2">Rust Bitcoin 0.28.2</a> is a minor release containing a fixes for bugs
that could “cause some specific transactions and/or blocks to fail to
deserialize. No known such transactions exist on any public
blockchain.”</p>
</li>
<li id="bitcoin-core-24-0-rc3" class="anchor-list">
<p><a href="#bitcoin-core-24-0-rc3" class="anchor-list-link">●</a> <a href="https://bitcoincore.org/bin/bitcoin-core-24.0/">Bitcoin Core 24.0 RC3</a> is a release candidate for the
next version of the network’s most widely used full node
implementation. A <a href="https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Candidate-Testing-Guide">guide to testing</a> is available.</p>
<p><strong>Warning:</strong> this release candidate includes the <code class="highlighter-rouge">mempoolfullrbf</code>
configuration option which several protocol and application developers
believe could lead to problems for merchant services as described in
this newsletter and previous newsletters <a href="/en/newsletters/2022/10/19/#transaction-replacement-option">#222</a> and
<a href="/en/newsletters/2022/10/26/#continued-discussion-about-full-rbf">#223</a>. It could also cause problems for transaction
relay as described in <a href="/en/newsletters/2022/11/02/#mempool-consistency">Newsletter #224</a>. Optech
encourages any services that might be affected to evaluate the RC and
participate in the public discussion.</p>
</li>
</ul>
<h2 id="notable-code-and-documentation-changes">Notable code and documentation changes</h2>
<p><em>Notable changes this week in <a href="https://github.com/bitcoin/bitcoin">Bitcoin Core</a>, <a href="https://github.com/ElementsProject/lightning">Core
Lightning</a>, <a href="https://github.com/ACINQ/eclair">Eclair</a>, <a href="https://github.com/lightningdevkit/rust-lightning">LDK</a>,
<a href="https://github.com/lightningnetwork/lnd/">LND</a>, <a href="https://github.com/bitcoin-core/secp256k1">libsecp256k1</a>, <a href="https://github.com/bitcoin-core/HWI">Hardware Wallet
Interface (HWI)</a>, <a href="https://github.com/rust-bitcoin/rust-bitcoin">Rust Bitcoin</a>, <a href="https://github.com/btcpayserver/btcpayserver/">BTCPay
Server</a>, <a href="https://github.com/bitcoindevkit/bdk">BDK</a>, <a href="https://github.com/bitcoin/bips/">Bitcoin Improvement
Proposals (BIPs)</a>, and <a href="https://github.com/lightning/bolts">Lightning BOLTs</a>.</em></p>
<ul>
<li id="bitcoin-core-26419" class="anchor-list">
<p><a href="#bitcoin-core-26419" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin/bitcoin/issues/26419">Bitcoin Core #26419</a> adds context to the validation interface logs
detailing why a transaction is removed from the mempool.</p>
</li>
<li id="eclair-2404" class="anchor-list">
<p><a href="#eclair-2404" class="anchor-list-link">●</a> <a href="https://github.com/ACINQ/eclair/issues/2404">Eclair #2404</a> adds support for Short Channel IDentifier (SCID)
aliases and <a href="/en/topics/zero-conf-channels/">zero-conf channels</a>
even for channel state commitments that don’t use <a href="/en/topics/anchor-outputs/">anchor
outputs</a>.</p>
</li>
<li id="eclair-2468" class="anchor-list">
<p><a href="#eclair-2468" class="anchor-list-link">●</a> <a href="https://github.com/ACINQ/eclair/issues/2468">Eclair #2468</a> implements <a href="https://github.com/lightning/bolts/issues/1032">BOLTs #1032</a>, allowing the ultimate receiver of a payment (<a href="/en/topics/htlc/">HTLC</a>) to accept a greater amount than they requested and with a
longer time before it expires than they requested. Previously,
Eclair-based receivers adhered to <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md">BOLT4</a>’s requirement that the
amount and expiry delta equal exactly the amount they requested, but
that exactitude meant a forwarding node could probe the next hop to
see if it was the final receiver by changing either value by the
slightest bit.</p>
</li>
<li id="eclair-2469" class="anchor-list">
<p><a href="#eclair-2469" class="anchor-list-link">●</a> <a href="https://github.com/ACINQ/eclair/issues/2469">Eclair #2469</a> extends the amount of time it asks the last
forwarding node to give the next hop to settle a payment. The last
forwarding node shouldn’t know it’s the last forwarding node—it
shouldn’t know that the next hop is the receiver of the payment. The
extra settlement time implies that the next hop may be a routing node
rather than the receiver. The PR description for this feature states
that Core Lightning and LDK already implement this behavior. See also
the description for Eclair #2468 above.</p>
</li>
<li id="eclair-2362" class="anchor-list">
<p><a href="#eclair-2362" class="anchor-list-link">●</a> <a href="https://github.com/ACINQ/eclair/issues/2362">Eclair #2362</a> adds support for the <code class="highlighter-rouge">dont_forward</code> flag for channel
updates from <a href="https://github.com/lightning/bolts/issues/999">BOLTs #999</a>. Channel updates change the parameters of
a channel and are often gossiped to inform other nodes on the network
about how to use the channel, but when a channel update contains this
flag, it should not be forwarded to other nodes.</p>
</li>
<li id="eclair-2441" class="anchor-list">
<p><a href="#eclair-2441" class="anchor-list-link">●</a> <a href="https://github.com/ACINQ/eclair/issues/2441">Eclair #2441</a> allows Eclair to begin receiving onion-wrapped error
messages of any size. <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md">BOLT2</a> currently recommends 256 byte errors,
but doesn’t forbid longer error messages and <a href="https://github.com/lightning/bolts/issues/1021">BOLTs #1021</a> is open to
encourage use of 1024-byte error messages encoded using LN’s modern
Type-Length-Value (TLV) semantics.</p>
</li>
<li id="lnd-7100" class="anchor-list">
<p><a href="#lnd-7100" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/issues/7100">LND #7100</a> updates LND to use the latest version of BTCD (as a
library), fixing the block parsing bug described in the <em>news</em> section
above.</p>
</li>
<li id="ldk-1761" class="anchor-list">
<p><a href="#ldk-1761" class="anchor-list-link">●</a> <a href="https://github.com/lightningdevkit/rust-lightning/issues/1761">LDK #1761</a> adds a <code class="highlighter-rouge">PaymentID</code> parameter to methods for sending
payments which callers can use to prevent sending multiple identical
payments. Additionally, LDK may now continue trying to resend a
payment indefinitely, rather than the previous behavior of ceasing
retries after a few blocks of repeated failures; the <code class="highlighter-rouge">abandon_payment</code>
method may be used to prevent further retrying.</p>
</li>
<li id="ldk-1743" class="anchor-list">
<p><a href="#ldk-1743" class="anchor-list-link">●</a> <a href="https://github.com/lightningdevkit/rust-lightning/issues/1743">LDK #1743</a> provides a new <code class="highlighter-rouge">ChannelReady</code> event when a channel
becomes ready to use. Notably, the event may be issued after a
channel has received a suitable number of confirmations, or it may be
issued immediately in the case of a <a href="/en/topics/zero-conf-channels/">zero-conf channel</a>.</p>
</li>
<li id="btcpay-server-4157" class="anchor-list">
<p><a href="#btcpay-server-4157" class="anchor-list-link">●</a> <a href="https://github.com/btcpayserver/btcpayserver/issues/4157">BTCPay Server #4157</a> adds opt-in support for a new version of the
checkout interface. See the PR for screenshots and video previews.</p>
</li>
<li id="bolts-1032" class="anchor-list">
<p><a href="#bolts-1032" class="anchor-list-link">●</a> <a href="https://github.com/lightning/bolts/issues/1032">BOLTs #1032</a> allows the ultimate receiver of a payment
(<a href="/en/topics/htlc/">HTLC</a>) to accept a greater amount than they requested
and with a longer time before it expires than they requested. This
makes it more difficult for a forwarding node to determine that the
next hop is the receiver by slightly tweaking a payment’s parameters.
See the description of Eclair #2468 above for more information.</p>
</li>
</ul>Bitcoin OptechThis week’s newsletter summarizes continued discussion about a configuration option for enabling full-RBF in Bitcoin Core and describes a bug affecting BTCD, LND, and other software. Also included are our regular sections with the summary of a Bitcoin Core PR Review Club meeting, descriptions of new releases and release candidates, and overviews of notable changes to popular Bitcoin infrastructure software.Bitcoin Optech Newsletter #2242022-11-02T00:00:00+00:002022-11-02T00:00:00+00:00https://bitcoinops.org/en/newsletters/2022/11/2022-11-02-newsletter<p>This week’s newsletter describes continued discussion about optionally
allowing nodes to enable full RBF, relays a request for feedback on a
design element of the BIP324 version 2 encrypted transport protocol,
summarizes a proposal for reliably attributing LN failures and delays to
particular nodes, and links to a discussion about an alternative to
using anchor outputs for modern LN HTLCs. Also included are our regular
sections with the announcements of new software releases and release
candidates—including a security critical update for LND—and
descriptions of notable changes to popular Bitcoin infrastructure
software.</p>
<h2 id="news">News</h2>
<ul>
<li id="mempool-consistency" class="anchor-list">
<p><a href="#mempool-consistency" class="anchor-list-link">●</a> <strong>Mempool consistency:</strong> Anthony Towns started a <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021116.html">discussion</a> on the Bitcoin-Dev mailing list about the consequences of
making it easier to configure Bitcoin Core’s policies for transaction
relay and mempool acceptance, such as was done by the addition of the
<code class="highlighter-rouge">mempoolfullrbf</code> option to Bitcoin Core’s development branch (see
Newsletters <a href="/en/newsletters/2022/06/22/#full-replace-by-fee">#205</a>, <a href="/en/newsletters/2022/07/13/#bitcoin-core-25353">#208</a>, <a href="/en/newsletters/2022/10/19/#transaction-replacement-option">#222</a>, and <a href="/en/newsletters/2022/10/26/#continued-discussion-about-full-rbf">#223</a>). He claims that “this differs from
what core has done in the past, in that previously we’ve tried to
ensure a new policy is good for everyone (or as nearly as it can be),
and then enabled it as soon as it’s implemented. Any options that
have been added have either been to control resource usage in ways
that don’t significantly [affect] tx propagation, to allow people to
revert to the old behaviour when the new behaviour is controversial
(eg the -mempoolreplacement=0 option from 0.12 to 0.18), and to make
it easier to test/debug the implementation. Giving people a new relay
behaviour they can opt-in to when we aren’t confident enough to turn
on by default doesn’t match the approach I’ve seen core take in the
past.”</p>
<p>Towns then contemplates whether this is a new direction for
development: “full <a href="/en/topics/replace-by-fee/">RBF</a> has been controversial for ages,
but widely liked by devs […] so maybe this is just a special case
and not a precedent, and when people propose other default false
options, there will be substantially more resistance to them being
merged, despite all the talk about users having options that’s going
on right now.” But, assuming it is a new direction, he evaluates
some potential consequences of that decision:</p>
<ul>
<li id="it-should-be-easier-to-get-default-disabled-alternative-relay-options-merged" class="anchor-list">
<p><a href="#it-should-be-easier-to-get-default-disabled-alternative-relay-options-merged" class="anchor-list-link">●</a> <em>It should be easier to get default-disabled alternative relay options merged:</em>
if giving users more options is seen as better, there are many
aspects of relay policy that can be made configurable. For
example, Bitcoin Knots provides a script pubkey reuse
(<code class="highlighter-rouge">spkreuse</code>) option for configuring a node to refuse to relay
any transactions which <a href="/en/topics/output-linking/">reuse an address</a>.</p>
</li>
<li id="more-permissive-policies-require-widespread-acceptance-or-better-peering" class="anchor-list">
<p><a href="#more-permissive-policies-require-widespread-acceptance-or-better-peering" class="anchor-list-link">●</a> <em>More permissive policies require widespread acceptance or better peering:</em>
A Bitcoin Core node by default relays transactions with eight peers via outbound connections,
so at least 30% of the network needs to support a more
permissive policy before a node has a 95% chance of finding at
least one randomly-selected peer that supports the same policy.
The fewer nodes that support a policy, the less likely it is
that a node will find a peer supporting that policy.</p>
</li>
<li id="better-peering-involves-tradeoffs" class="anchor-list">
<p><a href="#better-peering-involves-tradeoffs" class="anchor-list-link">●</a> <em>Better peering involves tradeoffs:</em> Bitcoin nodes can announce
their capabilities using the services field of the P2P <code class="highlighter-rouge">addr</code>,
<a href="/en/topics/addr-v2/"><code class="highlighter-rouge">addrv2</code></a>, and <code class="highlighter-rouge">version</code> messages, allowing nodes
with common interests to find each other and form sub-networks
(called <em>preferential peering</em>). Alternatively, full node
operators with common interests can use other software to form
independent relay networks (such as a network among LN nodes).
This can make relay effective even when just a few nodes
implement a policy, but nodes implementing a rare policy are
easier to identify and censor. It also requires miners to
join these sub-networks and alternative networks, raising the
complexity and cost of mining. That increases the pressure to
centralize transaction selection, which also makes censorship
easier.</p>
<p>Additionally, nodes implementing different policies from some
of their peers won’t be able to take full advantage of
technologies like <a href="/en/topics/compact-block-relay/">compact block relay</a> and <a href="/en/topics/erlay/">erlay</a> for minimizing latency and
bandwidth when two peers already have some of the same
information.</p>
</li>
</ul>
<p>Towns’s post received multiple insightful responses, with discussion
ongoing as of this writing. We will provide an update in next
week’s newsletter.</p>
</li>
<li id="bip324-message-identifiers" class="anchor-list">
<p><a href="#bip324-message-identifiers" class="anchor-list-link">●</a> <strong>BIP324 message identifiers:</strong> Pieter Wuille <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021115.html">posted</a>
to the Bitcoin-Dev mailing list a response to the update of the
<a href="https://github.com/bitcoin/bips/issues/1378">BIP324</a> draft specification for the <a href="/en/topics/v2-p2p-transport/">version 2 P2P encrypted
transport protocol</a> (v2 transport). To save
bandwidth, v2 transport allows replacing the existing protocol’s
12-byte message names with identifiers as short as 1 byte. For
example, the <code class="highlighter-rouge">version</code> message name, which is padded out to 12 bytes,
could be replaced with 0x00. However, shorter message names increase
the risk of conflict between different future proposals to add
messages to the network. Wuille describes the tradeoffs between four
different approaches to this problem and requests opinions about the
subject from the community.</p>
</li>
<li id="ln-routing-failure-attribution" class="anchor-list">
<p><a href="#ln-routing-failure-attribution" class="anchor-list-link">●</a> <strong>LN routing failure attribution:</strong> LN payment attempts can end in
failure for a variety of reasons, from the ultimate receiver refusing
to release the payment preimage to one of the routing nodes
temporarily being offline. Information about which nodes caused a
payment to fail would be extremely useful to spenders for avoiding
those nodes for near-future payments, but the LN protocol today
doesn’t provide any authenticated method for routing nodes to
communicate that information to a spender.</p>
<p>Several years ago, Joost Jager proposed a solution (see <a href="/en/newsletters/2019/06/19/#authenticating-messages-about-ln-delays">Newsletter
#51</a>), which he has now <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003723.html">updated</a> with
improvements and additional details. The mechanism would ensure
identification of the pair of nodes between which a payment failed
(or between which one of them an earlier failure message was
censored or became garbled). The main downside of Jager’s proposal
is that it would significantly increase the size of LN onion
messages for failures if other LN properties remained the same,
although the size of onion messages for failures wouldn’t need to be
as large if the maximum number of LN hops was decreased.</p>
<p>Alternatively, Rusty Russell <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003727.html">suggested</a> that a
spender could use a mechanism similar to <a href="/en/topics/spontaneous-payments/">spontaneous
payments</a> where each routing node is paid
one sat even if the ultimate payment fails. The spender could then
identify which hop the payment failed at by comparing how many
satoshis it sent to how many satoshis it received back.</p>
</li>
<li id="anchor-outputs-workaround" class="anchor-list">
<p><a href="#anchor-outputs-workaround" class="anchor-list-link">●</a> <strong>Anchor outputs workaround:</strong> Bastien Teinturier <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003729.html">posted</a> to the Lightning-Dev mailing list a <a href="https://github.com/lightning/bolts/issues/1036">proposal</a> for using
<a href="/en/topics/anchor-outputs/">anchor outputs</a> with multiple presigned
versions of each <a href="/en/topics/htlc/">HTLC</a> at different feerates. Anchor
outputs were introduced with the development of the <a href="/en/topics/cpfp-carve-out/">CPFP
carve-out</a> rule for allowing fees to be added to
a transaction via the <a href="/en/topics/cpfp/">CPFP</a> mechanism in a way that
wouldn’t be <a href="/en/topics/transaction-pinning/">pinnable</a> for LN’s two-party
contract protocol. However, Teinturier <a href="https://github.com/lightning/bolts/issues/845">notes</a> that using
CPFP requires every LN node keep a pool of non-LN UTXOs ready to spend
at any moment. By comparison, presigning multiple versions of HTLCs
each with different fees allows those fees to be paid directly from
the HTLC’s value—no additional UTXO management is required, except in
cases where none of the presigned feerates was high enough.</p>
<p>He’s seeking support from other LN developers for the idea of providing
multiple feerate HTLCs. All discussion as of this writing has
occurred on Teinturier’s <a href="https://github.com/lightning/bolts/issues/1036">PR</a>.</p>
</li>
</ul>
<h2 id="releases-and-release-candidates">Releases and release candidates</h2>
<p><em>New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
release candidates.</em></p>
<ul>
<li id="lnd-0-15-4-beta" class="anchor-list">
<p><a href="#lnd-0-15-4-beta" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/releases/tag/v0.15.4-beta">LND 0.15.4-beta</a> and <a href="https://github.com/lightningnetwork/lnd/releases/tag/v0.14.5-beta">0.14.4-beta</a> are <strong>security
critical</strong> releases containing a bug fix for a problem processing
recent blocks. All users should upgrade.</p>
</li>
<li id="bitcoin-core-24-0-rc2" class="anchor-list">
<p><a href="#bitcoin-core-24-0-rc2" class="anchor-list-link">●</a> <a href="https://bitcoincore.org/bin/bitcoin-core-24.0/">Bitcoin Core 24.0 RC2</a> is a release candidate for the
next version of the network’s most widely used full node
implementation. A <a href="https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Candidate-Testing-Guide">guide to testing</a> is available.</p>
<p><strong>Warning:</strong> this release candidate includes the <code class="highlighter-rouge">mempoolfullrbf</code>
configuration option which several protocol and application developers
believe could lead to problems for merchant services as described
in newsletters <a href="/en/newsletters/2022/10/19/#transaction-replacement-option">#222</a> and <a href="/en/newsletters/2022/10/26/#continued-discussion-about-full-rbf">#223</a>. Optech
encourages any services that might be affected to evaluate the RC and
participate in the public discussion.</p>
</li>
</ul>
<h2 id="notable-code-and-documentation-changes">Notable code and documentation changes</h2>
<p><em>Notable changes this week in <a href="https://github.com/bitcoin/bitcoin">Bitcoin Core</a>, <a href="https://github.com/ElementsProject/lightning">Core
Lightning</a>, <a href="https://github.com/ACINQ/eclair">Eclair</a>, <a href="https://github.com/lightningdevkit/rust-lightning">LDK</a>,
<a href="https://github.com/lightningnetwork/lnd/">LND</a>, <a href="https://github.com/bitcoin-core/secp256k1">libsecp256k1</a>, <a href="https://github.com/bitcoin-core/HWI">Hardware Wallet
Interface (HWI)</a>, <a href="https://github.com/rust-bitcoin/rust-bitcoin">Rust Bitcoin</a>, <a href="https://github.com/btcpayserver/btcpayserver/">BTCPay
Server</a>, <a href="https://github.com/bitcoindevkit/bdk">BDK</a>, <a href="https://github.com/bitcoin/bips/">Bitcoin Improvement
Proposals (BIPs)</a>, and <a href="https://github.com/lightning/bolts">Lightning BOLTs</a>.</em></p>
<ul>
<li id="bitcoin-core-23927" class="anchor-list">
<p><a href="#bitcoin-core-23927" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin/bitcoin/issues/23927">Bitcoin Core #23927</a> restricts <code class="highlighter-rouge">getblockfrompeer</code> on pruned nodes
to heights below the node’s current synchronization progress. This
prevents a footgun arising from retrieving future blocks making the
node’s block-files ineligible for pruning.</p>
<p>Bitcoin Core stores blocks in files of about 130 MB in whatever order
it receives them. Pruning will discard entire block files, but will not
discard any file containing a block not processed by synchronization.
The combination of a small data allowance and repeated use of the
<code class="highlighter-rouge">getblockfrompeer</code> RPC could cause multiple block-files ineligible for
pruning, and cause a pruned node to exceed its data allowance.</p>
</li>
<li id="bitcoin-core-25957" class="anchor-list">
<p><a href="#bitcoin-core-25957" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin/bitcoin/issues/25957">Bitcoin Core #25957</a> improves the performance of rescans for
descriptor wallets by using the <a href="/en/topics/compact-block-filters/">block filter index</a> (if enabled)
to skip blocks that don’t spend or create UTXOs relevant to the wallet.</p>
</li>
<li id="bitcoin-core-23578" class="anchor-list">
<p><a href="#bitcoin-core-23578" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin/bitcoin/issues/23578">Bitcoin Core #23578</a> uses <a href="/en/topics/hwi/">HWI</a> and recently merged support for
<a href="https://github.com/bitcoin/bips/blob/master/bip-0371.mediawiki">BIP371</a> (see <a href="/en/newsletters/2022/07/06/#bitcoin-core-22558">Newsletter #207</a>) to allow external signing
support for <a href="/en/topics/taproot/">taproot</a> keypath spends.</p>
</li>
<li id="core-lightning-5646" class="anchor-list">
<p><a href="#core-lightning-5646" class="anchor-list-link">●</a> <a href="https://github.com/ElementsProject/lightning/issues/5646">Core Lightning #5646</a> updates the experimental implementation of
<a href="/en/topics/offers/">offers</a> to remove <a href="/en/newsletters/2019/11/13/#x-only-pubkeys">x-only public keys</a>
(instead using <a href="https://developer.bitcoin.org/devguide/wallets.html#public-key-formats">compressed pubkeys</a>, which contain an extra byte).
It also implements forwarding of <a href="/en/topics/rendez-vous-routing/">blinded payments</a>, another
experimental protocol. The PR description warns it “does not include
generating and actually paying invoices with blinded payments.”</p>
</li>
<li id="lnd-6517" class="anchor-list">
<p><a href="#lnd-6517" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/issues/6517">LND #6517</a> adds a new RPC and event that allow a user to monitor
when an incoming payment (<a href="/en/topics/htlc/">HTLC</a>) is fully locked in by
the commitment transaction being updated to reflect the new channel
balance distribution.</p>
</li>
<li id="lnd-7001" class="anchor-list">
<p><a href="#lnd-7001" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/issues/7001">LND #7001</a> adds new fields to the forwarding history RPC
(<code class="highlighter-rouge">fwdinghistory</code>) indicating which channel partner forwarded a payment
(HTLC) to us and the partner to whom we relayed the payment.</p>
</li>
<li id="lnd-6831" class="anchor-list">
<p><a href="#lnd-6831" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/issues/6831">LND #6831</a> updates the HTLC interceptor implementation (see
<a href="/en/newsletters/2020/07/01/#lnd-4018">Newsletter #104</a>) to automatically reject an
incoming payment (HTLC) if the client connected to the interceptor
hasn’t finished processing it within a reasonable amount of time. If
an HTLC isn’t accepted or rejected before its expiry draws near, the
channel partner will need to force close the channel to protect its
funds. This merged PR’s automatic rejection before that expiry
ensures the channel stays open. The spender can always try to send
the payment again.</p>
</li>
</ul>
<!-- The commit below appears to be a direct push to LND's master branch -->
<ul>
<li id="lnd-609cc8b" class="anchor-list">
<p><a href="#lnd-609cc8b" class="anchor-list-link">●</a> <a href="https://github.com/LightningNetwork/lnd/commit/609cc8b883c7e6186e447e8d7e6349688d78d4fd">LND 609cc8b</a> adds a <a href="https://github.com/lightningnetwork/lnd/security/policy">security policy</a>, including
instructions for reporting vulnerabilities.</p>
</li>
<li id="rust-bitcoin-957" class="anchor-list">
<p><a href="#rust-bitcoin-957" class="anchor-list-link">●</a> <a href="https://github.com/rust-bitcoin/rust-bitcoin/issues/957">Rust Bitcoin #957</a> adds an API for signing <a href="/en/topics/psbt/">PSBTs</a>.
It does not support signing <a href="/en/topics/taproot/">taproot</a> spends yet.</p>
</li>
<li id="bdk-779" class="anchor-list">
<p><a href="#bdk-779" class="anchor-list-link">●</a> <a href="https://github.com/bitcoindevkit/bdk/issues/779">BDK #779</a> adds support for <a href="/en/topics/low-r-grinding/">low-r grinding</a>
of ECDSA signatures, which allows reducing the size for about half of
all signatures by one byte.</p>
</li>
</ul>Bitcoin OptechThis week’s newsletter describes continued discussion about optionally allowing nodes to enable full RBF, relays a request for feedback on a design element of the BIP324 version 2 encrypted transport protocol, summarizes a proposal for reliably attributing LN failures and delays to particular nodes, and links to a discussion about an alternative to using anchor outputs for modern LN HTLCs. Also included are our regular sections with the announcements of new software releases and release candidates—including a security critical update for LND—and descriptions of notable changes to popular Bitcoin infrastructure software.Bitcoin Optech Newsletter #2232022-10-26T00:00:00+00:002022-10-26T00:00:00+00:00https://bitcoinops.org/en/newsletters/2022/10/2022-10-26-newsletter<p>This week’s newsletter summarizes continued discussion about enabling
full RBF, provides overviews for several transcripts of discussions at a
CoreDev.tech meeting, and describes a proposal for ephemeral anchor
outputs designed for contract protocols like LN. Also included are our
regular sections with summaries of popular questions and answers from
the Bitcoin Stack Exchange, a list of new software releases and release
candidates, and descriptions of notable changes to popular Bitcoin
infrastructure software.</p>
<h2 id="news">News</h2>
<ul>
<li id="continued-discussion-about-full-rbf" class="anchor-list">
<p><a href="#continued-discussion-about-full-rbf" class="anchor-list-link">●</a> <strong>Continued discussion about full RBF:</strong> in <a href="/en/newsletters/2022/10/19/#transaction-replacement-option">last week’s
newsletter</a>, we summarized a discussion on the
Bitcoin-Dev mailing list about the inclusion of a new <code class="highlighter-rouge">mempoolfullrbf</code>
option that could create problems for several businesses which
accept transactions with zero confirmations (“zero conf”) as final
payments. Discussion continued this week on both the mailing list and
the #bitcoin-core-dev IRC room. Some highlights of the discussion
include:</p>
<ul>
<li id="free-option-problem" class="anchor-list">
<p><a href="#free-option-problem" class="anchor-list-link">●</a> <em>Free option problem:</em> Sergej Kotliar <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021056.html">warned</a> that he believes the greatest problem with any type of transaction
replacement is that it creates a free American call option. For
example, customer Alice requests to buy widgets from merchant Bob.
Bob gives Alice an invoice for 1 BTC at the current price of
$20,000 USD/BTC. Alice sends Bob the 1 BTC in a transaction with
a low feerate. The transaction remains unconfirmed when the
exchange rate changes to $25,000 USD/BTC, meaning Alice is now
paying $5,000 more. At this point, she quite rationally chooses
to replace her transaction with one paying the BTC back to
herself, effectively canceling the transaction. However, if instead the
exchange rate had changed in Alice’s favor (e.g. $15,000 USD/BTC), Bob
can’t cancel Alice’s payment and so he has no way in the normal
onchain Bitcoin transaction flow to exercise the same option,
creating an asymmetric exchange rate risk. By comparison, when
transaction replacement isn’t possible, Alice and Bob share the
same exchange rate risk.</p>
<p>Kotliar notes that the problem exists today with <a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki">BIP125</a>
opt-in <a href="/en/topics/replace-by-fee/">RBF</a> being available, but believes that
full-RBF would make the problem worse.</p>
<p>Greg Sanders and Jeremy Rubin <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021060.html">replied</a> in
<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021059.html">separate</a> emails to note that merchant Bob could
incentivize miners to confirm customer Alice’s original
transaction using <a href="/en/topics/cpfp/">CPFP</a>, particularly if <a href="/en/topics/package-relay/">package
relay</a> was enabled.</p>
<p>Antoine Riard <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021067.html">noted</a> that the same risk
exists with LN, as Alice could wait to pay merchant Bob’s
invoice up until shortly before it expired, giving her time to
wait for the exchange rate to change. Although in that case, if
Bob noticed that the exchange rate had changed significantly, he
could instruct his node not to accept the payment, returning the
money to Alice.</p>
</li>
<li id="bitcoin-core-not-in-charge-of-network" class="anchor-list">
<p><a href="#bitcoin-core-not-in-charge-of-network" class="anchor-list-link">●</a> <em>Bitcoin Core not in charge of network:</em> Gloria Zhao <a href="https://www.erisian.com.au/bitcoin-core-dev/log-2022-10-20.html#l-440">wrote</a> in the IRC discussion, “I think whatever option we
take, it should be made abundantly clear to users that Core does
not control whether full RBF happens or not. We could revert
<a href="https://github.com/bitcoin/bitcoin/issues/25353">25353</a> and it could still happen. […]”</p>
<p>After the meeting, Zhao also posted a detailed <a href="https://github.com/glozow/bitcoin-notes/blob/full-rbf/full-rbf.md">overview</a> of the situation.</p>
</li>
<li id="no-removal-means-the-problem-could-happen" class="anchor-list">
<p><a href="#no-removal-means-the-problem-could-happen" class="anchor-list-link">●</a> <em>No removal means the problem could happen:</em> in the IRC discussion,
Anthony Towns <a href="https://www.erisian.com.au/bitcoin-core-dev/log-2022-10-20.html#l-488">echoed</a> his points from last
week, “if we’re not going to remove the <code class="highlighter-rouge">mempoolfullrbf</code> option from
24.0, we’re going for an uncoordinated deployment.”</p>
<p>Greg Sanders was <a href="https://www.erisian.com.au/bitcoin-core-dev/log-2022-10-20.html#l-490">doubtful</a>, “the question is:
will 5%+ set a variable? I suspect not.” Towns <a href="https://www.erisian.com.au/bitcoin-core-dev/log-2022-10-20.html#l-492">replied</a>, “<a href="/en/topics/soft-fork-activation/">UASF</a> <code class="highlighter-rouge">uacomment</code>
demonstrated it’s easy to get ~11% to set a variable in just a
couple of weeks”.</p>
</li>
<li id="should-be-an-option" class="anchor-list">
<p><a href="#should-be-an-option" class="anchor-list-link">●</a> <em>Should be an option:</em> Martin Zumsande <a href="https://www.erisian.com.au/bitcoin-core-dev/log-2022-10-20.html#l-493">said</a> in
the IRC discussion, “I think that if a meaningful number of node
operators and miners want a specific policy, it shouldn’t be on
the devs to tell them ‘you can’t have that now’. Devs can and
should give a recommendation (by picking the default), but
providing options to informed users should never be a problem.”</p>
</li>
</ul>
<p>As of this writing, no clear resolution had been reached. The
<code class="highlighter-rouge">mempoolfullrbf</code> option is still included in the release candidates
for the upcoming version of Bitcoin Core 24.0 and it is Optech’s
recommendation that any service depending on zero conf transactions
carefully evaluate the risks, perhaps starting by reading the emails
linked in <a href="/en/newsletters/2022/10/19/#transaction-replacement-option">last week’s newsletter</a>.</p>
</li>
<li id="coredev-tech-transcripts" class="anchor-list">
<p><a href="#coredev-tech-transcripts" class="anchor-list-link">●</a> <strong>CoreDev.tech transcripts:</strong> prior to The Atlanta Bitcoin Conference
(TabConf), about 40 developers participated in a CoreDev.tech event.
<a href="https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/">Transcripts</a> for about half of the meetings from the event
have been provided by Bryan Bishop. Notable discussions included:</p>
<ul>
<li id="transport-encryption" class="anchor-list">
<p><a href="#transport-encryption" class="anchor-list-link">●</a> <a href="https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2022-10-10-p2p-encryption/">Transport encryption</a>: a conversation about the
recent update to the <a href="/en/topics/v2-p2p-transport/">version 2 encrypted transport
protocol</a> proposal (see
<a href="/en/newsletters/2022/10/19/#bip324-update">Newsletter #222</a>). This protocol would make it
harder for network eavesdroppers to learn which IP address
originated a transaction and improve the ability to detect and
resist man-in-the-middle attacks between honest nodes.</p>
<p>The discussion covers several of the protocol design
considerations and is a recommended read for anyone wondering
why the protocol authors made certain decisions. It also
examines the relationship to the earlier <a href="/en/topics/countersign/">countersign</a> authentication protocol.</p>
</li>
<li id="fees" class="anchor-list">
<p><a href="#fees" class="anchor-list-link">●</a> <a href="https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2022-10-11-fee-market/">Fees</a>: a wide-ranging discussion about transaction fees
historically, presently, and in the future. Some topics included
queries about why blocks are seemingly almost always nearly full
but the mempool isn’t, debate about how long we have for a significant
fee market to develop before we have to <a href="/en/topics/fee-sniping/">worry</a>
about Bitcoin’s long-term stability, and what solutions we could
deploy if we did believe a problem existed.</p>
</li>
<li id="frost" class="anchor-list">
<p><a href="#frost" class="anchor-list-link">●</a> <a href="https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2022-10-11-frost/">FROST</a>: a presentation about the FROST threshold signature
scheme. The transcript documents several excellent technical
questions about the cryptographic choices in the design and may
be useful reading for anyone interested in learning more
about FROST specifically or cryptographic protocol design in
general. See also the TabConf transcript about <a href="https://diyhpl.us/wiki/transcripts/tabconf/2022/roast/">ROAST</a>, another
threshold signature scheme for Bitcoin.</p>
</li>
<li id="github" class="anchor-list">
<p><a href="#github" class="anchor-list-link">●</a> <a href="https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2022-10-11-github/">GitHub</a>: a discussion about moving the Bitcoin Core
project’s git hosting from GitHub to another issue and PR
management solution, as well as considering the benefits of
continuing to use GitHub.</p>
</li>
<li id="provable-specifications-in-bips" class="anchor-list">
<p><a href="#provable-specifications-in-bips" class="anchor-list-link">●</a> <a href="https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2022-10-11-hac-spec/">Provable specifications in BIPs</a>: part of a discussion
about using the <a href="https://hacspec.github.io/">hacspec</a> specification language in BIPs to
provide specifications that are provably correct. See also the
<a href="https://diyhpl.us/wiki/transcripts/tabconf/2022/hac-spec/">transcript</a> for a related talk during the TabConf.</p>
</li>
<li id="package-and-v3-transaction-relay" class="anchor-list">
<p><a href="#package-and-v3-transaction-relay" class="anchor-list-link">●</a> <a href="https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2022-10-11-package-relay/">Package and v3 transaction relay</a>: the
transcript of a presentation about proposals to enable <a href="/en/topics/package-relay/">package
transaction relay</a> and use new transaction
relay rules to eliminate <a href="/en/topics/transaction-pinning/">pinning attacks</a> in certain cases.</p>
</li>
<li id="stratum-v2" class="anchor-list">
<p><a href="#stratum-v2" class="anchor-list-link">●</a> <a href="https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2022-10-11-stratum-v2/">Stratum v2</a>: a discussion that started with the
announcement of a new open-source project implementing the Stratum
version 2 pooled mining protocol. Improvements made available by
Stratum v2 include authenticated connections and the ability for
individual miners (those with local mining equipment) to choose
which transactions to mine (rather than the pool choosing
transactions). In addition to many other benefits, it was
mentioned in the discussion that allowing individual miners to
choose their own block template might become highly desirable to
pools that are worried about governments mandating which
transactions can be mined, as in the <a href="https://www.coincenter.org/analysis-what-is-and-what-is-not-a-sanctionable-entity-in-the-tornado-cash-case/">Tornado Cash</a> controversy.
Most of the discussion focused on the changes that would need to
be made to Bitcoin Core to enable native support for Stratum v2.
See also the TabConf transcript about <a href="https://diyhpl.us/wiki/transcripts/tabconf/2022/braidpool/">Braidpool</a>,
a decentralized pooled mining protocol.</p>
</li>
<li id="merging" class="anchor-list">
<p><a href="#merging" class="anchor-list-link">●</a> <a href="https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2022-10-12-merging/">Merging</a> is a discussion about strategies to help
get code reviewed in the Bitcoin Core project, although many
suggestions also apply to other projects. Ideas included:</p>
<ul>
<li>
<p>Break big changes into several small PRs</p>
</li>
<li>
<p>Make it easy for reviewers to understand the ultimate
objective. For all PRs, this means writing a motivational PR
description. For changes that are being made incrementally,
use tracking issues, project boards, and motivate
refactorings by also opening the PRs that will use that
refactored code to accomplish a desirable goal</p>
</li>
<li>
<p>Produce high-level explainers for long-running projects
describing the state before the project, the current progress,
what it will take to accomplish the outcome, and the benefits
that will provide to users</p>
</li>
<li>
<p>Form working groups with those who are interested in the same
projects or code subsystems</p>
</li>
</ul>
</li>
</ul>
</li>
<li id="ephemeral-anchors" class="anchor-list">
<p><a href="#ephemeral-anchors" class="anchor-list-link">●</a> <strong>Ephemeral anchors:</strong> Greg Sanders followed up previous discussion
about v3 transaction relay (see <a href="/en/newsletters/2022/10/05/#ephemeral-dust">Newsletter #220</a>)
with a <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021036.html">post</a> to the Bitcoin-Dev mailing containing
a proposal for a new type of <a href="/en/topics/anchor-outputs/">anchor output</a>. A
v3 transaction could pay zero fees but contain an output paying the
script <code class="highlighter-rouge">OP_TRUE</code>, allowing anyone to spend it under the consensus
rules in a child transaction. The unconfirmed zero-fee parent transaction would
only be relayed and mined by Bitcoin Core if it was part of a transaction package which also
contained the child transaction spending the OP_TRUE output. This
would only affect Bitcoin Core’s policy; no consensus rules would be
changed.</p>
<p>Described advantages of this proposal include that it eliminates the need
to use one-block relative timelocks (called <code class="highlighter-rouge">1 OP_CSV</code> after the
code used to enable them) to prevent <a href="/en/topics/transaction-pinning/">transaction pinning</a> and allows anyone to fee bump the parent
transaction (similar to an earlier <a href="/en/topics/fee-sponsorship/">fee sponsorship</a> soft fork proposal).</p>
<p>Jeremy Rubin <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021041.html">replied</a> in support of the proposal
but noted that it doesn’t work for any contract that can’t use v3
transactions. Several other developers also discussed the concept,
all of them seeming to find it appealing as of this writing.</p>
</li>
</ul>
<h2 id="selected-qa-from-bitcoin-stack-exchange">Selected Q&A from Bitcoin Stack Exchange</h2>
<p><em><a href="https://bitcoin.stackexchange.com/">Bitcoin Stack Exchange</a> is one of the first places Optech
contributors look for answers to their questions—or when we have a
few spare moments to help curious or confused users. In
this monthly feature, we highlight some of the top-voted questions and
answers posted since our last update.</em></p>
<ul>
<li id="why-would-someone-use-a-1-of-1-multisig" class="anchor-list">
<p><a href="#why-would-someone-use-a-1-of-1-multisig" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/115443">Why would someone use a 1-of-1 multisig?</a>
Vojtěch Strnad asks why someone would choose to use 1-of-1 multisig over
P2WPKH given P2WPKH is cheaper and has a larger anonymity set. Murch lists a
variety of resources showing at least one entity spending millions of 1-of-1
UTXOs over the years, although the motivations remain unclear.</p>
</li>
<li id="why-would-a-transaction-have-a-locktime-in-the-year-1987" class="anchor-list">
<p><a href="#why-would-a-transaction-have-a-locktime-in-the-year-1987" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/115549">Why would a transaction have a locktime in the year 1987?</a>
1440000bytes points to a comment from Christian Decker referencing <a href="https://github.com/lightning/bolts/blob/316882fcc5c8b4cf9d798dfc73049075aa89d3e9/03-transactions.md#commitment-transaction">a section</a>
from the BOLT 3 Lightning spec that allocates the locktime field as “upper 8
bits are 0x20, lower 24 bits are the lower 24 bits of the obscured commitment
transaction number”.</p>
</li>
<li id="what-is-the-size-limit-on-the-utxo-set-if-any" class="anchor-list">
<p><a href="#what-is-the-size-limit-on-the-utxo-set-if-any" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/115439">What is the size limit on the UTXO set, if any?</a>
Pieter Wuille answers that there is no consensus limit on the UTXO set size and that the
rate of growth of the UTXO set is bounded by the block size which limits the
number of UTXOs that can be created in a given block. In a <a href="https://bitcoin.stackexchange.com/questions/111234/how-many-useable-utxos-are-possible-with-btc-inside-them/115451#115451">related answer</a>, Murch estimates that it would take about 11 years to create
a UTXO for every person on Earth.</p>
</li>
<li id="why-is-blockmaxweight-set-to-3996000-by-default" class="anchor-list">
<p><a href="#why-is-blockmaxweight-set-to-3996000-by-default" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/115499">Why is <code class="highlighter-rouge">-blockmaxweight</code> set to 3996000 by default?</a>
Vojtěch Strnad points out that the default setting for <code class="highlighter-rouge">-blockmaxweight</code> in
Bitcoin Core is 3,996,000 which is less than the segwit limit of 4,000,000
weight units (WU). Pieter Wuille explains that the difference allows
buffer space for a miner to add a larger coinbase transaction with additional
outputs beyond the default coinbase transaction created by the block template.</p>
</li>
<li id="can-a-miner-open-a-lightning-channel-with-a-coinbase-output" class="anchor-list">
<p><a href="#can-a-miner-open-a-lightning-channel-with-a-coinbase-output" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/115588">Can a miner open a Lightning channel with a coinbase output?</a>
Murch points out challenges with a miner creating a Lightning channel using an
output from their coinbase transaction including delays in closing the channel
given the coinbase maturation period as well as needing to continuously renegotiate the
channel open while hashing due to the coinbase transaction’s hash constantly
changing during mining.</p>
</li>
<li id="what-is-the-history-on-how-previous-soft-forks-were-tested-prior-to-being-considered-for-activation" class="anchor-list">
<p><a href="#what-is-the-history-on-how-previous-soft-forks-were-tested-prior-to-being-considered-for-activation" class="anchor-list-link">●</a> <a href="https://bitcoin.stackexchange.com/a/115434">What is the history on how previous soft forks were tested prior to being considered for activation?</a>
Michael Folkson quotes a <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020964.html">recent mailing list post</a> from Anthony Towns which
describes the testing around the P2SH, CLTV, CSV, segwit, <a href="/en/topics/taproot/">taproot</a>, CTV, and <a href="/en/topics/sidechains/">Drivechain</a> proposals.</p>
</li>
</ul>
<h2 id="releases-and-release-candidates">Releases and release candidates</h2>
<p><em>New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
release candidates.</em></p>
<ul>
<li id="ldk-0-0-112" class="anchor-list">
<p><a href="#ldk-0-0-112" class="anchor-list-link">●</a> <a href="https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.0.112">LDK 0.0.112</a> is a release of this library for building LN-enabled
applications.</p>
</li>
<li id="bitcoin-core-24-0-rc2" class="anchor-list">
<p><a href="#bitcoin-core-24-0-rc2" class="anchor-list-link">●</a> <a href="https://bitcoincore.org/bin/bitcoin-core-24.0/">Bitcoin Core 24.0 RC2</a> is a release candidate for the
next version of the network’s most widely used full node
implementation. A <a href="https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Candidate-Testing-Guide">guide to testing</a> is available.</p>
<p><strong>Warning:</strong> this release candidate includes the <code class="highlighter-rouge">mempoolfullrbf</code>
configuration option which several protocol and application developers
believe could lead to problems for merchant services as described
in the newsletters for this week and last week. Optech encourages any
services that might be affected to evaluate the RC and participate in
the public discussion.</p>
</li>
</ul>
<h2 id="notable-code-and-documentation-changes">Notable code and documentation changes</h2>
<p><em>Notable changes this week in <a href="https://github.com/bitcoin/bitcoin">Bitcoin Core</a>, <a href="https://github.com/ElementsProject/lightning">Core
Lightning</a>, <a href="https://github.com/ACINQ/eclair">Eclair</a>, <a href="https://github.com/lightningdevkit/rust-lightning">LDK</a>,
<a href="https://github.com/lightningnetwork/lnd/">LND</a>, <a href="https://github.com/bitcoin-core/secp256k1">libsecp256k1</a>, <a href="https://github.com/bitcoin-core/HWI">Hardware Wallet
Interface (HWI)</a>, <a href="https://github.com/rust-bitcoin/rust-bitcoin">Rust Bitcoin</a>, <a href="https://github.com/btcpayserver/btcpayserver/">BTCPay
Server</a>, <a href="https://github.com/bitcoindevkit/bdk">BDK</a>, <a href="https://github.com/bitcoin/bips/">Bitcoin Improvement
Proposals (BIPs)</a>, and <a href="https://github.com/lightning/bolts">Lightning BOLTs</a>.</em></p>
<ul>
<li id="bitcoin-core-23443" class="anchor-list">
<p><a href="#bitcoin-core-23443" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin/bitcoin/issues/23443">Bitcoin Core #23443</a> adds a new P2P protocol message,
<code class="highlighter-rouge">sendtxrcncl</code> (send transaction reconciliation), that allows a node to
signal to a peer that it supports <a href="/en/topics/erlay/">erlay</a>. This PR adds
just the first part of the erlay protocol—other parts are needed
before it can be used.</p>
</li>
<li id="eclair-2463" class="anchor-list">
<p><a href="#eclair-2463" class="anchor-list-link">●</a> <a href="https://github.com/ACINQ/eclair/issues/2463">Eclair #2463</a> and <a href="https://github.com/ACINQ/eclair/issues/2461">#2461</a> update Eclair’s
implementation of the <a href="/en/topics/dual-funding/">interactive and dual funding protocols</a> to require every funding input opt-in to <a href="/en/topics/replace-by-fee/">RBF</a> and also be confirmed (i.e. spend an output that’s already in the
block chain). These changes ensure RBF can be used and that none of
the fees contributed by an Eclair user will be used to help confirm any
of their peer’s previous transactions.</p>
</li>
</ul>Bitcoin OptechThis week’s newsletter summarizes continued discussion about enabling full RBF, provides overviews for several transcripts of discussions at a CoreDev.tech meeting, and describes a proposal for ephemeral anchor outputs designed for contract protocols like LN. Also included are our regular sections with summaries of popular questions and answers from the Bitcoin Stack Exchange, a list of new software releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.Bitcoin Optech Newsletter #2222022-10-19T00:00:00+00:002022-10-19T00:00:00+00:00https://bitcoinops.org/en/newsletters/2022/10/2022-10-19-newsletter<p>This week’s newsletter describes the block parsing bug affecting BTCD
and LND last week, summarizes discussion about a planned Bitcoin Core
feature change related to replace by fee, outlines research about
validity rollups on Bitcoin, shares an announcement about a
vulnerability in the draft BIP for MuSig2, examines a proposal to reduce
the minimum size of an unconfirmed transaction that Bitcoin Core will
relay, and links to an update of the BIP324 proposal for a version 2
encrypted transport protocol for Bitcoin. Also included are our regular
sections with summaries of changes to services and client software,
announcements of new releases and release candidates, and descriptions
of notable merges to popular Bitcoin infrastructure projects.</p>
<h2 id="news">News</h2>
<ul>
<li id="block-parsing-bug-affecting-btcd-and-lnd" class="anchor-list">
<p><a href="#block-parsing-bug-affecting-btcd-and-lnd" class="anchor-list-link">●</a> <strong>Block parsing bug affecting BTCD and LND:</strong> on October 9th, a
<a href="https://twitter.com/brqgoo/status/1579216353780957185">user</a> created a <a href="https://blockstream.info/tx/7393096d97bfee8660f4100ffd61874d62f9a65de9fb6acf740c4c386990ef73?expand">transaction</a> using <a href="/en/topics/taproot/">taproot</a> with a witness containing nearly a thousand signatures. The
consensus rules for taproot don’t place any direct limits on the size
of witness data. This was a design element discussed during taproot’s
development (see <a href="/en/newsletters/2019/09/25/#tapscript-resource-limits">Newsletter #65</a>).</p>
<p>Shortly after the large-witness transaction was confirmed, users
began to report that the BTCD full node implementation and LND
Lightning Network implementation were failing to provide data from
the most recent blocks that were available to Bitcoin Core full
nodes. For BTCD nodes, this meant that transactions which had been
recently confirmed were being reported as still unconfirmed. For
LND, it meant that new channels that had recently become ready to
use weren’t being reported as fully open.</p>
<p>A developer for both BTCD and LND fixed the problem in BTCD’s code,
which LND uses as a library, and quickly released new versions for
both <a href="https://github.com/lightningnetwork/lnd/releases/tag/v0.15.2-beta">LND</a> (as mentioned in <a href="/en/newsletters/2022/10/12/#lnd-v0-15-2-beta">last week’s
newsletter</a>) and <a href="https://github.com/btcsuite/btcd/releases/tag/v0.23.2">BTCD</a>. All users of
BTCD and LND should upgrade.</p>
<p>Until a user upgrades their software, they will suffer the
lack-of-confirmation problems described above and may also be
vulnerable to several attacks. Some of those attacks require access
to significant hash rate (making them expensive and, hopefully,
impractical in this case). Other attacks, particularly those
against LND users, require the attacker to risk losing some of their
funds in a channel, which is also hopefully a sufficient deterrent.
We again recommend upgrade and, further, we recommend that anyone
using any Bitcoin software sign up for security announcements from
that software’s development team.</p>
<p>After the above disclosures, Loki Verloren <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020993.html">posted</a>
to the Bitcoin-Dev mailing list to suggest that direct limits be
added to taproot’s witness size. Greg Sanders <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020996.html">replied</a> to note that adding limits now would not only increase code
complexity but could also lead to people losing their money if they
already received bitcoins to a script which requires a large witness
to spend.</p>
</li>
<li id="transaction-replacement-option" class="anchor-list">
<p><a href="#transaction-replacement-option" class="anchor-list-link">●</a> <strong>Transaction replacement option:</strong> as reported in Newsletters
<a href="/en/newsletters/2022/06/22/#full-replace-by-fee">#205</a> and <a href="/en/newsletters/2022/07/13/#bitcoin-core-25353">#208</a>, Bitcoin Core merged
support for a <code class="highlighter-rouge">mempoolfullrbf</code> configuration option which defaults to
the existing Bitcoin Core behavior of only allowing <a href="/en/topics/replace-by-fee/">RBF
replacement</a> of transactions containing the <a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki">BIP125</a>
signal. However, if a user sets the new option to true, their node
will accept and relay replacements for transactions that don’t contain the
BIP125 signal, provided the replacement transactions follow all of
Bitcoin Core’s other rules for replacements.</p>
<p>Dario Sneidermanis <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020980.html">posted</a> to the Bitcoin-Dev mailing list that
this new option may create problems for services which currently accept
unconfirmed transactions as final. Although it’s been possible for
years for users to run non-Bitcoin Core software (or patched
versions of Bitcoin Core) that allow unsignaled <em>full</em><sup id="fnref:full-rbf"><a href="#fn:full-rbf" class="footnote">1</a></sup>
transaction replacement, there’s no evidence that software
is widely used. Sneidermanis believes an easily accessible
option in Bitcoin Core might change that by allowing enough users
and miners to enable full RBF and make unsignaled replacement
reliable. More reliable unsignaled replacement would also make it
more reliable to steal from services that accept unconfirmed transactions
as final, requiring those services to change their behavior.</p>
<p>In addition to describing the problem and providing a detailed
description of how services choose when to accept unconfirmed
transactions,
Sneidermanis also proposed an alternative approach: remove the configuration
option from the upcoming Bitcoin Core release but also add code that
will enable full RBF by default at a future moment. Anthony Towns
<a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021017.html">posted</a> several options for consideration and opened a
<a href="https://github.com/bitcoin/bitcoin/issues/26323">pull request</a> that implements a slightly
modified version of Sneidermanis’s proposal. If merged and released
in its current state, Towns’s PR will enable full RBF by default
starting 1 May 2023. Users objecting to full RBF will still be able
to prevent their nodes from participating by setting the
<code class="highlighter-rouge">mempoolfullrbf</code> option to false.</p>
</li>
<li id="validity-rollups-research" class="anchor-list">
<p><a href="#validity-rollups-research" class="anchor-list-link">●</a> <strong>Validity rollups research:</strong> John Light <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020998.html">posted</a> to the
Bitcoin-Dev mailing list a link to a <a href="https://bitcoinrollups.org/">detailed research report</a> he prepared about validity rollups—a type of <a href="/en/topics/sidechains/">sidechain</a> where the current sidechain state is compactly stored on
the mainchain. A user of the
sidechain can use the state stored on the mainchain to prove how
many sidechain bitcoins they control. By submitting a mainchain
transaction with a validity proof, they can withdraw bitcoins they own from the
sidechain even if the operators or miners of the
sidechain try to prevent the withdrawal.</p>
<p>Light’s research describes validity rollups in depth, looks at how
support for them could be added to Bitcoin, and examines various
concerns with their implementation.</p>
</li>
<li id="musig2-security-vulnerability" class="anchor-list">
<p><a href="#musig2-security-vulnerability" class="anchor-list-link">●</a> <strong>MuSig2 security vulnerability:</strong> Jonas Nick <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021000.html">posted</a> to
the Bitcoin-Dev mailing list about a vulnerability he and several
others discovered in the <a href="/en/topics/musig/">MuSig2</a> algorithm as documented
in a <a href="https://github.com/bitcoin/bips/issues/1372">draft BIP</a>. In short, the protocol is vulnerable if
an attacker knows a user’s public key, a tweak to that public key that
the user will sign for (such as with <a href="/en/topics/hd-key-generation/">BIP32</a> extended
pubkeys), and can manipulate which version of the key the user will
sign for.</p>
<p>Jonas Nick believes the vulnerability “should only apply in
relatively rare cases” and encourages anyone using (or soon planning
to use) MuSig2 to reach out to him and his co-authors with
questions. The draft BIP for MuSig2 is expected to be updated soon
to address the issue.</p>
</li>
<li id="minimum-relayable-transaction-size" class="anchor-list">
<p><a href="#minimum-relayable-transaction-size" class="anchor-list-link">●</a> <strong>Minimum relayable transaction size:</strong> Greg Sanders <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020995.html">posted</a> to the Bitcoin-Dev mailing list a request for Bitcoin Core to
relax a policy added to make it harder to exploit the
<a href="/en/topics/cve/#CVE-2017-12842">CVE-2017-12842</a> vulnerability. This vulnerability allows an
attacker who can get a specially-crafted 64 byte transaction confirmed
into a block to trick lightweight clients into believing one or more
different arbitrary transactions were confirmed. E.g., innocent user
Bob’s Simplified Payment Verification (SPV) wallet might display that
he’d received a million BTC payment with dozens of confirmations even
though no such payment was ever confirmed.</p>
<p>When the vulnerability was only privately known among a few
developers, a limit was added to Bitcoin Core preventing relay of
any transaction with fewer than 85 bytes (not counting witness
bytes), which is about the smallest size that can be created using
standard transaction templates. This would require an attacker to
get their transaction mined by software not based on Bitcoin Core.
Later, the <a href="/en/topics/consensus-cleanup-soft-fork/">consensus cleanup soft fork proposal</a> suggested permanently fixing the problem by disallowing any
transactions less than 65 bytes in size from being included in new
blocks.</p>
<p>Sanders suggests lowering the transaction relay policy limit from 85
bytes to the 65 byte limit suggested in consensus cleanup, which may
allow additional experimentation and usage without changing the
current risk profile. Sanders has a <a href="https://github.com/bitcoin/bitcoin/issues/26265">pull request</a> open to make this change. See also <a href="/en/newsletters/2020/05/27/#minimum-transaction-size-discussion">Newsletter #99</a> for prior discussion related to this proposed change.</p>
</li>
<li id="bip324-update" class="anchor-list">
<p><a href="#bip324-update" class="anchor-list-link">●</a> <strong>BIP324 update:</strong> Dhruv M <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/020985.html">posted</a> to the Bitcoin-Dev
mailing list a summary of several updates to the BIP324 proposal for a
<a href="/en/topics/v2-p2p-transport/">version 2 encrypted P2P transport protocol</a>.
This includes a rewrite of the <a href="https://github.com/bitcoin/bips/issues/1378">draft BIP</a> and the
publication of a <a href="https://bip324.com">variety of resources</a> to help reviewers
evaluate the proposal, including an excellent <a href="https://bip324.com/sections/code-review/">guide to the proposed
code changes</a> across multiple repositories.</p>
<p>As described in the draft BIP’s <em>motivation</em> section, a native
encrypted transport protocol for Bitcoin nodes can improve privacy
during transaction announcement, prevent tampering with connections
(or at least make it easier to detect tampering), and also make P2P
connection censorship and <a href="/en/topics/eclipse-attacks/">eclipse attacks</a>
more difficult.</p>
</li>
</ul>
<h2 id="changes-to-services-and-client-software">Changes to services and client software</h2>
<p><em>In this monthly feature, we highlight interesting updates to Bitcoin
wallets and services.</em></p>
<ul>
<li id="btcd-v0-23-2-released" class="anchor-list">
<p><a href="#btcd-v0-23-2-released" class="anchor-list-link">●</a> <strong>btcd v0.23.2 released:</strong>
btcd v0.23.2 (and <a href="https://github.com/btcsuite/btcd/releases/tag/v0.23.1">v0.23.1</a>) adds <a href="/en/topics/addr-v2/">addr v2</a> and additional
support for <a href="/en/topics/psbt/">PSBTs</a>, <a href="/en/topics/taproot/">taproot</a>, and <a href="/en/topics/musig/">MuSig2</a> as well as other enhancements and fixes.</p>
</li>
<li id="zebedee-announces-hosted-channel-libraries" class="anchor-list">
<p><a href="#zebedee-announces-hosted-channel-libraries" class="anchor-list-link">●</a> <strong>ZEBEDEE announces hosted channel libraries:</strong>
In a recent <a href="https://blog.zebedee.io/announcing-nbd/">blog post</a>, ZEBEDEE announced an open source wallet (Open
Bitcoin Wallet), Core Lightning plugin (Poncho), Lightning client (Cliché),
and Lightning library (Immortan) which focus on support for <a href="https://fanismichalakis.fr/posts/what-are-hosted-channels/">hosted channels</a>.</p>
</li>
<li id="cashu-launches-with-lightning-support" class="anchor-list">
<p><a href="#cashu-launches-with-lightning-support" class="anchor-list-link">●</a> <strong>Cashu launches with Lightning support:</strong>
E-cash software <a href="https://github.com/callebtc/cashu">Cashu</a> launches as a proof-of-concept wallet with
Lightning receive support.</p>
</li>
<li id="address-explorer-spiral-launches" class="anchor-list">
<p><a href="#address-explorer-spiral-launches" class="anchor-list-link">●</a> <strong>Address explorer Spiral launches:</strong>
<a href="https://btc.usespiral.com/">Spiral</a> is an open source public address <a href="/en/topics/block-explorers/">explorer</a> that uses
cryptography to provide privacy to users querying information about an address.</p>
</li>
<li id="bitgo-announces-lightning-support" class="anchor-list">
<p><a href="#bitgo-announces-lightning-support" class="anchor-list-link">●</a> <strong>BitGo announces Lightning support:</strong>
In a <a href="https://blog.bitgo.com/bitgo-unveils-custodial-lightning-898554d3b749">blog post</a>, BitGo describes its custodial Lightning
service that runs nodes on behalf of its clients and maintains payment
channel liquidity.</p>
</li>
<li id="zerosync-project-launches" class="anchor-list">
<p><a href="#zerosync-project-launches" class="anchor-list-link">●</a> <strong>ZeroSync project launches:</strong>
The <a href="https://github.com/zerosync/zerosync">ZeroSync</a> project is using <a href="/en/topics/utreexo/">Utreexo</a> and
STARK proofs to sync a Bitcoin node, as occurs in Initial Block Download (IBD).</p>
</li>
</ul>
<h2 id="releases-and-release-candidates">Releases and release candidates</h2>
<p><em>New releases and release candidates for popular Bitcoin infrastructure
projects. Please consider upgrading to new releases or helping to test
release candidates.</em></p>
<ul>
<li id="bitcoin-core-24-0-rc2" class="anchor-list">
<p><a href="#bitcoin-core-24-0-rc2" class="anchor-list-link">●</a> <a href="https://bitcoincore.org/bin/bitcoin-core-24.0/">Bitcoin Core 24.0 RC2</a> is a release candidate for the
next version of the network’s most widely used full node
implementation. A <a href="https://github.com/bitcoin-core/bitcoin-devwiki/wiki/24.0-Release-Candidate-Testing-Guide">guide to testing</a> is available.</p>
</li>
<li id="lnd-0-15-3-beta" class="anchor-list">
<p><a href="#lnd-0-15-3-beta" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/releases/tag/v0.15.3-beta">LND 0.15.3-beta</a> is a minor release that fixes several bugs.</p>
</li>
</ul>
<h2 id="notable-code-and-documentation-changes">Notable code and documentation changes</h2>
<p><em>Notable changes this week in <a href="https://github.com/bitcoin/bitcoin">Bitcoin Core</a>, <a href="https://github.com/ElementsProject/lightning">Core
Lightning</a>, <a href="https://github.com/ACINQ/eclair">Eclair</a>, <a href="https://github.com/lightningdevkit/rust-lightning">LDK</a>,
<a href="https://github.com/lightningnetwork/lnd/">LND</a>, <a href="https://github.com/bitcoin-core/secp256k1">libsecp256k1</a>, <a href="https://github.com/bitcoin-core/HWI">Hardware Wallet
Interface (HWI)</a>, <a href="https://github.com/rust-bitcoin/rust-bitcoin">Rust Bitcoin</a>, <a href="https://github.com/btcpayserver/btcpayserver/">BTCPay
Server</a>, <a href="https://github.com/bitcoindevkit/bdk">BDK</a>, <a href="https://github.com/bitcoin/bips/">Bitcoin Improvement
Proposals (BIPs)</a>, and <a href="https://github.com/lightning/bolts">Lightning BOLTs</a>.</em></p>
<ul>
<li id="bitcoin-core-23549" class="anchor-list">
<p><a href="#bitcoin-core-23549" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin/bitcoin/issues/23549">Bitcoin Core #23549</a> adds the <code class="highlighter-rouge">scanblocks</code> RPC that identifies
relevant blocks in a given range for a provided set of <a href="/en/topics/output-script-descriptors/">descriptors</a>.
The RPC is only available on nodes that maintain a <a href="/en/topics/compact-block-filters/">compact block
filter</a> index (<code class="highlighter-rouge">-blockfilterindex=1</code>).</p>
</li>
<li id="bitcoin-core-25412" class="anchor-list">
<p><a href="#bitcoin-core-25412" class="anchor-list-link">●</a> <a href="https://github.com/bitcoin/bitcoin/issues/25412">Bitcoin Core #25412</a> adds a new <code class="highlighter-rouge">/deploymentinfo</code> REST endpoint which
contains information about soft fork deployments, similar to the
existing <code class="highlighter-rouge">getdeploymentinfo</code> RPC.</p>
</li>
<li id="lnd-6956" class="anchor-list">
<p><a href="#lnd-6956" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/issues/6956">LND #6956</a> allows configuring the minimum channel reserve enforced
on payments received from a channel’s partner. A node won’t accept a
payment from its channel partner if that would lower the amount of the
partner’s funds in the channel below the reserve, which is 1% by
default in LND. This ensures the partner will need to pay at least
the reserve amount as a penalty if it attempts to close a channel in a
outdated state. This merged PR allows lowering or raising the reserve
amount.</p>
</li>
<li id="lnd-7004" class="anchor-list">
<p><a href="#lnd-7004" class="anchor-list-link">●</a> <a href="https://github.com/lightningnetwork/lnd/issues/7004">LND #7004</a> updates the version of the BTCD library used by LND,
fixing the security vulnerability previously described in this
newsletter.</p>
</li>
<li id="ldk-1625" class="anchor-list">
<p><a href="#ldk-1625" class="anchor-list-link">●</a> <a href="https://github.com/lightningdevkit/rust-lightning/issues/1625">LDK #1625</a> begins tracking information about the liquidity of
distant channels which the local node has attempted to route payments
through. The local node stores information about the size of payments
which have either successfully been routed through the remote node or
which failed due to apparent insufficient funds. This information,
adjusted for its age, is used as input for probabilistic pathfinding
(see <a href="/en/newsletters/2021/08/25/#zero-base-fee-ln-discussion">Newsletter #163</a>).</p>
</li>
</ul>
<h2 id="footnotes">Footnotes</h2>
<!-- TODO:harding is 95% sure the below is correct and will delete this
comment when he gets verification from the person he thinks first used
the "full RBF" term. -->
<div class="footnotes">
<ol>
<li id="fn:full-rbf">
<p>Transaction replacement was included in the first version of Bitcoin
and has received much discussion over the years. During that time,
several terms used for describing aspects of it have changed,
leading to potential confusion. Perhaps the greatest source of
confusion would be the term “full RBF”, which has been used for two
different concepts:</p>
<ul>
<li id="full-replacement-of-any" class="anchor-list">
<p><a href="#full-replacement-of-any" class="anchor-list-link">●</a> <em>Full replacement of any <strong>part</strong> of a transaction</em> as distinct
from just adding additional inputs and outputs. During a period
when enabling RBF was controversial and before the idea of opt-in
RBF was proposed, one <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-March/002240.html">suggestion</a> was to allow a
transaction to be replaced only if the replacement included all of
the same outputs plus additional new inputs and outputs used to
pay fees and collect change. The requirement to keep the original
outputs ensured the replacement would still pay the original
receiver the same amount of money. This idea, later called First
Seen Safe (FSS) RBF, was a type of <em>partial</em> replacement.</p>
<p>By comparison, <em>full</em> replacement at this time meant the
replacement could fully change anything about the original
transaction (provided it still conflicted with the original
transaction by spending at least one of the same inputs). It’s
this usage of full that’s used in the title of <a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki">BIP125</a>,
“Opt-in Full Replace-by-Fee Signaling”.</p>
</li>
<li id="full-replacement-of" class="anchor-list">
<p><a href="#full-replacement-of" class="anchor-list-link">●</a> <em>Full replacement of <strong>any</strong> transaction</em> as distinct from only
replacing transactions that opt-in to allowing replacement via a
BIP125 signal. Opt-in RBF was proposed as a compromise between
people who didn’t want to allow RBF and those who believed it was
either necessary or inevitable. However, as of this writing,
only a minority of transactions opt-in to RBF, which can be seen as
partial adoption of RBF.</p>
<p>By comparison, <em>full</em> adoption of RBF can be enabled by allowing
any unconfirmed transaction to be replaced. It’s this usage of
full that’s used in the currently-discussed Bitcoin Core
configuration option, <code class="highlighter-rouge">mempoolfullrbf</code>.</p>
</li>
</ul>
<p><a href="#fnref:full-rbf" class="reversefootnote">↩</a></p>
</li>
</ol>
</div>Bitcoin OptechThis week’s newsletter describes the block parsing bug affecting BTCD and LND last week, summarizes discussion about a planned Bitcoin Core feature change related to replace by fee, outlines research about validity rollups on Bitcoin, shares an announcement about a vulnerability in the draft BIP for MuSig2, examines a proposal to reduce the minimum size of an unconfirmed transaction that Bitcoin Core will relay, and links to an update of the BIP324 proposal for a version 2 encrypted transport protocol for Bitcoin. Also included are our regular sections with summaries of changes to services and client software, announcements of new releases and release candidates, and descriptions of notable merges to popular Bitcoin infrastructure projects.