This week’s newsletter summarizes a discussion about griefing liquidity advertisements and includes our regular sections describing changes to services and client software, summarizing popular questions and answers of the Bitcoin Stack Exchange, announcing new software releases and release candidates, and examining recent changes to popular Bitcoin infrastructure software.

News

• ● Discussion about griefing liquidity ads: Bastien Teinturier posted to the Lightning-Dev mailing list about a potential problem with timelocks on dual-funded channels created from liquidity advertisements. This was also previously mentioned in Recap #279. For example, Alice advertises that, for a fee, she’s willing to commit 10,000 sats of her funds to a channel for 28 days. The 28-day timelock prevents Alice from simply closing the channel after she receives payment and using her funds for something else.

  Continuing the example, Bob opens the channel with an additional contribution of 100,000,000 sats (1 BTC) of his funds. He then sends almost all of his funds through the channel. Now Alice’s balance in the channel isn’t the 10,000 sats she received a fee for—it’s almost 10,000 times higher than that amount. If Bob is malicious, he won’t allow those funds to move again until the expiration of the 28-day timelock to which Alice committed.

  A mitigation suggested by Teinturier and discussed by him and others was to only apply the timelock to the liquidity contribution (e.g., only Alice’s 10,000 sats). This introduces complexities and inefficiencies, although it may solve the problem. An alternative that Teinturier proposed was simply dropping the timelock (or making it optional) and letting liquidity buyers take the risk that providers may close channels shortly after receiving their liquidity fees. If channels opened through liquidity ads typically generate significant forwarding fee income, there would be an incentive to keep channels open.

Changes to services and client software

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

• ● Stratum v2 mining pool launches: DEMAND is a mining pool built off of the Stratum v2 reference implementation initially allowing for solo mining, with pooled mining planned for the future.

• ● Bitcoin network simulation tool warnet announced: The warnet software allows for specifying node topologies, running scripted scenarios across that network, and monitoring and analyzing resulting behaviors.

• ● Payjoin client for Bitcoin Core released: The payjoin-cli is a rust project that adds command line payjoin sending and receiving capabilities for Bitcoin Core.

• ● Call for community block arrival timestamps: A contributor to the Bitcoin Block Arrival Time Dataset repository called for node operators to submit their block arrival timestamps for research. There is a similar repository for collecting stale block data.

• ● Envoy 1.4 released: Bitcoin wallet Envoy’s 1.4 release adds coin control and wallet labeling (BIP329 coming soon), among other features.

• ● BBQr encoding scheme announced: The scheme can efficiently encode larger files, for example PSBTs, into an animated QR series for use in air-gapped wallet configurations.

• ● Zeus v0.8.0 released: The v0.8.0 release contains an embedded LND node, additional zero conf channel support, and support for simple taproot channels, among other changes.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange 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.

• ● What are all the rules related to CPFP fee bumping? Pieter Wuille points out that contrary to the RBF fee bumping technique that has a list of associated policy rules, the CPFP fee bumping technique has no additional policy rules.

• ● How is the total number of RBF replaced transactions calculated? Murch and Pieter Wuille walk through some examples of RBF replacements in the context of BIP125’s rule 5: “The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions”. Readers may also be interested in the Add BIP-125 rule 5 testcase with default mempool PR Review Club meeting.

• ● What types of RBF exist and which one does Bitcoin Core support and use by default? Murch provides some of Bitcoin Core’s transaction replacement history and in a related question, a summary of RBF replacement rules and links to Bitcoin Core’s Mempool Replacements documentation and one developer’s ideas for RBF improvements.

• ● What is the Block 1,983,702 Problem? Antoine Poinsot gives an overview of the issues that led to BIP30 restricting duplicate txids and BIP34 mandating the inclusion of the current block height in the coinbase field. He then points out that there are numerous blocks whose random coinbase field content happens to match the mandatory height prefix of a later block. Block 1,983,702 being the first for which it would be practically possible to repeat the coinbase transaction of the prior block. In a related question, Murch and Antoine Poinsot evaluate that possibility in greater detail. See also Newsletter #182.

• ● What are hash functions used for in bitcoin? Pieter Wuille lists over thirty different instances across consensus rules, peer-to-peer protocol, wallet and node implementation details that make use of no less than 10 different hash functions.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

• ● LND 0.17.3-beta is a release that contains several bug fixes, including a reduction in memory when used with the Bitcoin Core backend.

Notable code and documentation changes

Notable recent changes 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.

• ● LDK #2685 adds the ability to obtain block chain data from an Electrum-style server.

• ● Libsecp256k1 #1446 removes some x86_64 assembly code from the project, switching to using existing C language code that has always been used for other platforms. The assembly code was human-optimized several years ago to improve performance but, in the meantime, compilers improved and recent versions of both GCC and LLVM (clang) now produce even more performant code.

• ● BTCPay Server #5389 adds support for BIP129 secure multisig wallet setup (see Newsletter #136). This allows BTCPay server to interact with multiple software wallets and hardware signing devices as part of a simple coordinated multisig setup procedure.

• ● BTCPay Server #5490 begins using fee estimates from mempool.space by default, with a fallback on fee estimates from the local Bitcoin Core node. Developers commenting on the PR noted that they felt Bitcoin Core’s fee estimates fail to respond quickly to changes in the local mempool. For previous related discussion about the challenges to improving fee estimation accuracy, see Bitcoin Core #27995.

Happy holidays!

This is Bitcoin Optech’s final regular newsletter of the year. On Wednesday, December 20th, we’ll publish our sixth annual year-in-review newsletter. Regular publication will resume on Wednesday, January 3rd.