This week’s newsletter warns of a wallet migration bug in Bitcoin Core, summarizes a post about using the Ark protocol as an LN channel factory, and links to a draft BIP for silent payment descriptors. Also included are our regular sections describing release candidates and notable changes to popular Bitcoin infrastructure software.

News

  • ● Bitcoin Core wallet migration bug: Bitcoin Core posted a notice of a bug in the legacy wallet migration feature in versions 30.0 and 30.1. Users of a Bitcoin Core legacy wallet who use an unnamed wallet, had not previously migrated their wallet to a descriptor wallet, and who attempt a migration in these versions, could, if the migration fails, have their wallet directory deleted, potentially resulting in a loss of funds. Wallet users should not attempt wallet migrations using the GUI or RPC until v30.2 is released (see Bitcoin Core 30.2rc1 below). Users of features other than legacy wallet migration can continue to use these Bitcoin Core versions as normal.

  • ● Using Ark as a channel factory: René Pickhardt wrote on Delving Bitcoin about his discussions and ideas around whether Ark’s best use case might be as a flexible channel factory rather than as an end-user payment solution. Pickhardt’s earlier research has focused on techniques to optimize payment success on the Lightning Network through routing and channel balancing. Ark-like structures containing Lightning channels have been discussed earlier (1, 2, 3).

    Pickhardt’s ideas focus on the possibility of many channel owners batching their channel liquidity changes (i.e. opens, closes, splices) using the vTXO structure of Ark as a way to significantly reduce the on-chain cost of operating the Lightning Network at the expense of additional liquidity overhead during the time between when one channel is forfeited and when its Ark batch fully expires. By using Ark batches as efficient channel factories, LSPs could provide liquidity to more end users efficiently, and the built-in expiration of the batches guarantees they can reclaim liquidity from idle channels without a costly dedicated on-chain force-close sequence. Routing nodes would also benefit from more efficient channel management operations by using regular batches to shift liquidity between their channels rather than individual splice operations.

    Greg Sanders replied that he’s been investigating similar possibilities, specifically using hArk to facilitate the (mostly) online transfer of a Lightning channel state from one batch to another. hArk would require CTV, OP_TEMPLATEHASH, or a similar opcode.

    Vincenzo Palazzo replied with his proof-of-concept code implementing an Ark channel factory.

  • ● Draft BIP for silent payment descriptors: Craig Raw posted to the Bitcoin-Dev mailing list a proposal for a draft BIP, which defines a new top-level descriptor script expression sp() for silent payments. According to Raw, the descriptor provides a standardized way to represent silent payment outputs within the output descriptor framework, enabling wallet interoperability and recovery using existing descriptor-based infrastructure.

    The sp() expression takes as an argument one of the two new key expressions, both defined in the same proposal:

    • spscan1q..: A bech32m encoding of the scan private key and the spend public key, with the q character representing silent payment version 0.

    • spspend1q..: A bech32m encoding of the scan private key and the spend private key, with the q character representing silent payment version 0.

    Optionally, the sp() expression can take as input arguments a BIRTHDAY, defined as a positive integer representing the block height at which scanning should begin (must be > 842579, the block height at which BIP352 was merged), and zero or more LABELs as integers used with the wallet.

    The output scripts produced by sp() are BIP341 taproot outputs as specified in BIP352.

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.

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.

  • ● Bitcoin Core #34156 and Bitcoin Core #34215 fix a bug in versions 30.0 and 30.1 where the entire wallets directory could be deleted accidentally. When migrating a legacy unnamed wallet fails, the cleanup logic is intended to remove only the newly created descriptor wallet directory. However, since an unnamed wallet resides directly in the top-level wallets directory, the entire directory was deleted. The second PR addresses a similar issue with the createfromdump command of wallettool (see Newsletters #45 and #130) when a wallet name is an empty string and the dump file contains a checksum error. Both fixes ensure that only the newly created wallet files are removed.

  • ● Bitcoin Core #34085 eliminates the separate FixLinearization() function by integrating its functionality into Linearize(); TxGraph now postpones fixing clusters until their first re-linearization. The number of calls to PostLinearize is reduced because the spanning-forest linearization (SFL) algorithm (see Newsletter #386) effectively performs similar work when loading an existing linearization. This is part of the cluster mempool project.

  • ● Bitcoin Core #34197 removes the startingheight field from the getpeerinfo RPC response, effectively deprecating it. Using the configuration option deprecatedrpc=startingheight retains the field in the response. The startingheight states a peer’s self-reported chaintip height when the connection was initiated. This deprecation is based on the idea that the starting height reported in a peer’s VERSION message is unreliable. It will be fully removed in the next major version.

  • ● Bitcoin Core #33135 adds a warning when importdescriptors is called with a miniscript descriptor containing an older() value (which specifies a timelock) that has no consensus meaning in BIP68 (relative timelocks) and BIP112 (OP_CSV). While some protocols, such as Lightning, intentionally use non-standard values to encode extra data, this practice is risky because the value may appear strongly timelocked when it is actually not delayed.

  • ● LDK #4213 sets blinded path defaults: when building a blinded path that is not for an offers context, it aims to maximize privacy by using a non-compact blinded path and pads it to four hops (including the recipient). When the blinded path is for an offer, the byte size is minimized by reducing the padding and attempting to build a compact blinded path.

  • ● Eclair #3217 adds an accountability signal for HTLCs, replacing the experimental HTLC endorsement signal. This aligns with the latest specification updates in BOLTs #1280 for channel jamming mitigations. The new proposal treats the signal as an accountability flag for scarce resources, indicating that protected HTLC capacity was used, and that downstream peers can be held responsible for a timely resolution.

  • ● LND #10367 renames the experimental endorsement signal from BLIP4 to accountable to align with the latest proposal in BLIPs #67, which is based on the proposed BOLTs #1280.

  • ● Rust Bitcoin #5450 adds validation to the transaction decoder to reject non-coinbase transactions that contain a null prevout, as dictated by a consensus rule.

  • ● Rust Bitcoin #5434 adds validation to the transaction decoder, rejecting coinbase transactions with a scriptSig length outside the 2–100 byte range.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 17:30 UTC on January 13. The discussion is also recorded and will be available from our podcasts page.