This week’s newsletter summarizes updates to a proposal for new LN channel announcements and describes a BIP for sending silent payments with PSBTs. Also included are our regular sections with popular questions and answers from the Bitcoin Stack Exchange, announcements of new releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.

News

• ● Updates to the version 1.75 channel announcements proposal: Elle Mouton posted to Delving Bitcoin a description of several proposed changes to the new channel announcements protocol that will support advertising simple taproot channels. The most significant planned change is to allow the messages to also announce current-style P2WSH channels; this will allow nodes to later “start switching off the legacy protocol […] when most of the network seems to have upgraded”.

  Another addition, recently discussed (see Newsletter #325), is to allow announcements to include an SPV proof so that any client that has all of the headers from the most-proof-of-work blockchain can verify that the channel’s funding transaction was included in a block. Currently, lightweight clients must download an entire block to perform the same level of verification of a channel announcement.

  Mouton’s post also briefly discusses allowing opt-in announcement of existing simple taproot channels. Due to the current lack of support for announcements of non-P2WSH channels, all existing taproot channels are unannounced. A possible feature that can be added to the proposal will allow nodes to signal to their peers that they want to convert an unannounced channel to a public channel.

• ● Draft BIP for sending silent payments with PSBTs: Andrew Toth posted to the Bitcoin-Dev mailing list a draft BIP for allowing wallets and signing devices to use PSBTs to coordinate the creation of a silent payment. This continues the previous discussion about an earlier iteration of the draft BIP, see Newsletters #304 and #308. As mentioned in those earlier newsletters, a special requirement of silent payments over most other PSBT-coordinated transactions is that any change to a not-fully-signed transaction’s inputs requires revising the outputs.

  The draft only addresses the expected most common situation where a signer has access to the private keys for all inputs in a transaction. For the less common situation of multiple signers, Toth writes that “this will be specified in a following BIP”.

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.

• ● Duplicate blocks in blk*.dat files? Pieter Wuille explains that, in addition to the current best chain of blocks, the block data files can also include stale blocks or duplicate block data.

• ● How was the structure of pay-to-anchor decided? Antoine Poinsot describes the structure of the pay-to-anchor (P2A) outputs included as part of Bitcoin Core 28.0’s policy changes. The bech32m encoded, 2-byte length, v1 witness program was chosen as a bc1pfeessrawgf vanity address.

• ● What are the benefits of decoy packets in BIP324? Pieter Wuille outlines design decisions around the inclusion of decoy packets in the BIP324 specification. The optional decoy packets can be used to obfuscate traffic patterns to prevent recognition by observers during the key exchange, application, and version negotiation phases of the protocol.

• ● Why is the opcode limit 201? Vojtěch Strnad points out code changes by Satoshi during 2010 that intended to introduce an opcode limit of 200, but due to an implementation error, actually introduced a limit of 201.

• ● Will my node relay a transaction if it is below my minimum tx relay fee? Murch notes that a node will only relay transactions that it accepts into its own mempool. While a user could decrease their node’s minTxRelayFee value to allow local mempool acceptance, the inclusion of a lower relay feerate transaction in a block would still ultimately require a miner running a similar setting and for average feerates to decrease toward that lower feerate.

• ● Why doesn’t the Bitcoin Core wallet support BIP69? Murch agrees that universal implementation of BIP69’s transaction input/output ordering specification would help mitigate wallet fingerprinting, but points out that given the unlikelihood of universal adoption, implementing BIP69 is itself a fingerprinting vulnerability.

• ● How can I enable testnet4 when using Bitcoin Core 28.0? Pieter Wuille mentions two configuration options that enable BIP94’s testnet4: chain=testnet4 and testnet4=1.

• ● What are the risks of broadcasting a transaction that reveals a scriptPubKey using a low-entropy key? User Quuxplusone links to a recent transaction associated with a series of Bitcoin key-grinding “puzzles” from 2015 that is theorized to have been replaced by a bot monitoring the mempool for low-entropy keys.

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.

• ● Core Lightning 24.08.2 is a maintenance release of this popular LN implementation that contains a “few crash fixes and includes an enhancement to remember and update channel hints for payments”.

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, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

• ● Eclair #2925 introduces support for using RBF with splicing transactions via the new rbfsplice API command, which triggers a tx_init_rbf and tx_ack_rbf message exchange for peers to agree to replace the transaction. This feature is only enabled for non-zero-conf channels, to prevent potential theft of funds on zero-conf channels. Chains of unconfirmed splice transactions are allowed on zero-conf channels, but not on non-zero-conf channels. In addition, RBF is blocked on liquidity purchase transactions via the liquidity advertisement protocol, to avoid edge cases where sellers might add liquidity to a channel without receiving payment.

• ● LND #9172 adds a new mac_root_key flag to the lncli create and lncli createwatchonly commands for deterministic macaroon (authentication token) generation, allowing external keys to be baked into an LND node before it’s even initialized. This is particularly useful in combination with the reverse remote signer setup suggested in LND #8754 (see Newsletter #172).

• ● Rust Bitcoin #2960 turns the ChaCha20-Poly1305 authenticated encryption with associated data (AEAD) algorithm into its own crate, allowing it to be used beyond just the v2 transport protocol specified in BIP324, such as for payjoin V2. The code has been optimized for Single Instruction, Multiple Data (SIMD) instruction support to improve performance across various use cases (see Newsletter #264).