This week’s newsletter includes the final entry in our limited weekly series about mempool policy, plus our regular sections describing notable changes to clients, services, and popular Bitcoin infrastructure software.

News

No significant news was found this week on the Bitcoin-Dev or Lightning-Dev mailing lists.

Waiting for confirmation #10: Get Involved

The final entry in our limited weekly series about transaction relay, mempool inclusion, and mining transaction selection—including why Bitcoin Core has a more restrictive policy than allowed by consensus and how wallets can use that policy most effectively.

We hope this series has given readers a better idea of what’s going on while they are waiting for confirmation. We started with a discussion about how some of the ideological values of Bitcoin translate to its structure and design goals. The distributed structure of the peer-to-peer network offers increased censorship resistance and privacy over a typical centralized model. An open transaction relay network helps everybody learn about transactions in blocks prior to confirmation, which improves block relay efficiency, makes joining as a new miner more accessible, and creates a public auction for block space. As the ideal network consists of many independent, anonymous entities running nodes, node software must be designed to protect against DoS and generally minimize operational costs.

Fees play an important role in the Bitcoin network as the “fair” way to resolve competition for block space. Mempools with transaction replacement and package-aware selection and eviction algorithms use incentive compatibility to measure the utility of storing a transaction, and enable RBF and CPFP as fee-bumping mechanisms for users. The combination of these mempool policies, wallets that construct transactions economically, and good feerate estimation create an efficient market for block space that benefits everybody.

Individual nodes also enforce transaction relay policy to protect themselves against resource exhaustion and express personal preference. At a network-wide level, standardness rules and other policies protect resources that are critical to scaling, accessibility of running a node, and ability to update consensus rules. As the vast majority of the network enforces these policies, they are an important part of the interface that Bitcoin applications and L2 protocols build upon. They also aren’t perfect. We described several policy-related proposals that address broad limitations and specific use cases such as pinning attacks on L2 settlement transactions.

We also highlighted that the ongoing evolution of network policies requires collaboration between developers working on protocols, applications, and wallets. As the Bitcoin ecosystem grows with respect to software, use cases, and users, a decentralized decision-making process becomes more necessary but also more challenging. Even as Bitcoin adoption grows, the system emerges from the concerns and efforts of its stakeholders – there is no company in charge of gathering customer feedback and hiring engineers to build new protocol features or remove unused features. Stakeholders who wish to be part of the rough consensus of the network have different avenues of participating: informing themselves, surfacing questions and issues, involving themselves in the design of the network, or even contributing to the implementation of improvements. Next time your transaction is taking too long to confirm, you know what to do!

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

• ● Wallet 10101 beta testing pooling funds between LN and DLCs: 10101 announced a wallet built with LDK and BDK that allows users to trade derivatives non-custodially using DLCs in an offchain contract that can also be used to send, receive, and forward LN payments. The DLCs rely on oracles that use adaptor signatures for price attestation.

• ● LDK Node announced: The LDK team announced LDK Node v0.1.0. LDK Node is a Lightning node Rust library that uses the LDK and BDK libraries to enable developers to quickly setup a self-custodial Lightning node while still providing a high degree of customization for different use cases.

• ● Payjoin SDK announced: Payjoin Dev Kit (PDK) was announced as a Rust library that implements BIP78 for use in wallets and services that wish to integrate payjoin functionality.

• ● Validating Lightning Signer (VLS) beta announced: VLS allows the separation of a Lightning node from the keys that control its funds. A Lightning node running with VLS will route signing requests to a remote signing device instead of local keys. The beta release supports CLN and LDK, layer-1 and layer-2 validation rules, backup/recovery capabilities, and provides a reference implementation. The blog post announcement also calls for testing, feature requests, and feedback from the community.

• ● BitGo adds MuSig2 support: BitGo announced support for BIP327 (MuSig2) and noted the reduced fees and additional privacy compared to their other supported address types.

• ● Peach adds RBF support: The Peach Bitcoin mobile application for peer-to-peer exchange announced support for Replace-By-Fee (RBF) fee bumping.

• ● Phoenix wallet adds splicing support: ACINQ announced beta testing for the next version of their Phoenix mobile Lightning wallet. The wallet supports a single dynamic channel that is rebalanced using splicing and a mechanism similar to the swap-in-potentiam technique (see Podcast #259).

• ● Mining Development Kit call for feedback: The team working on the Mining Development Kit (MDK) has posted an update on their progress to develop hardware, software, and firmware for Bitcoin mining systems. The post calls for feedback from the community about use cases, scope, and approach.

• ● Binance adds Lightning support: Binance announced support for sending (withdrawals) and receiving (deposits) using the Lightning Network.

• ● Nunchuk adds CPFP support: Nunchuk announced support for Child-Pays-For-Parent (CPFP) fee bumping for both senders and receivers of a transaction.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, and Bitcoin Inquisition.

• ● Bitcoin Core #27411 prevents a node from advertising its Tor or I2P address to peers on other networks (such as plain IPv4 or IPv6) and won’t advertise its address from non-anonymity networks to peers on Tor and I2P. This helps prevent someone from associating a node’s regular network address to one of its addresses on an anonymity network. CJDNS is treated differently from Tor and I2P at the moment, although that may change in the future.

• ● Core Lightning #6347 adds the ability for a plugin to subscribe to every event notification using the wildcard *.

• ● Core Lightning #6035 adds the ability to request a bech32m address for receiving deposits to P2TR output scripts. Transaction change will also now be sent to a P2TR output by default.

• ● LND #7768 implements BOLTs #1032 and #1063 (see Newsletter #225), allowing the ultimate receiver of a payment (HTLC) to accept a greater amount than they requested and with a longer time before it expires than they requested. Previously, LND-based receivers adhered to BOLT4’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 slightly changing either value.

• ● Libsecp256k1 #1313 begins automatic testing using development snapshots of the GCC and Clang compilers which may allow detection of changes that could result in certain libsecp256k1 code running in variable time. Non-constant time code that works with private keys and nonces may lead to side-channel attacks. See Newsletter #246 for one occasion where that may have happened and Newsletter #251 for another occasion and an announcement that this sort of testing was planned.