This week’s newsletter includes 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 software.

News

No significant news this week was found in any of our sources.

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.

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.

  • ● Bitcoin Core 28.4 is a maintenance release for a previous major release series of the predominant full node implementation. It primarily contains wallet migration fixes and removal of an unreliable DNS seed. See the release notes for details.

  • ● Core Lightning 26.04rc1 is a release candidate for the next major version of this popular LN node which includes many splicing updates and bug fixes.

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 #33259 adds a backgroundvalidation field to the getblockchaininfo RPC response for nodes using assumeUTXO snapshots. The new field reports the snapshot height, the current block height and hash for background validation, median time, chainwork, and verification progress. Previously, getblockchaininfo’s response would simply indicate that verification and IBD were complete with no information on the background validation.

  • ● Bitcoin Core #33414 enables Tor proof of work defenses for automatically created onion services when supported by the connected Tor daemon. When a Tor daemon has an accessible control port and Bitcoin Core’s listenonion setting is on (default), it will automatically create a hidden service. This doesn’t apply to manually created onion services, but it’s suggested that users add HiddenServicePoWDefensesEnabled 1 to enable proof of work defenses.

  • ● Bitcoin Core #34846 adds the functions btck_transaction_get_locktime and btck_transaction_input_get_sequence to the libbitcoinkernel C API (see Newsletter #380) for accessing timelock fields: a transaction’s nLockTime and an input’s nSequence. This allows checking BIP54 (consensus cleanup) rules such as coinbase nLockTime constraints without manually deserializing the transaction (other BIP54 rules, such as sigops limits, still require separate handling).

  • ● Core Lightning #8450 extends CLN’s splice scripting engine to handle cross-channel splices, multi-channel splices (more than three), and dynamic fee calculation. A key problem this solves is the circular dependency in fee estimation: adding wallet inputs increases transaction weight and therefore the required fee, which may in turn require additional inputs. This infrastructure underlies the new splicein and spliceout RPCs.

  • ● Core Lightning #8856 and #8857 add splicein and spliceout RPC commands for adding funds from the internal wallet into a channel and for removing funds from a channel to the internal wallet, a Bitcoin address, or another channel (effectively a cross-splice). The new commands avoid operators having to construct splicing transactions manually with the experimental dev-splice RPC.

  • ● Eclair #3247 adds an optional peer-scoring system that tracks per-peer forwarding revenue and payment volume over time. When enabled, it periodically ranks peers by profitability and can optionally auto-fund channels to top-earning peers, auto-close unproductive channels to reclaim liquidity, and auto-adjust relay fees based on volume, all within configurable bounds. Operators can start with visibility only before opting into automation.

  • ● LDK #4472 fixes a potential funds-loss scenario during channel funding and splicing where tx_signatures could be sent before the counterparty’s commitment signature was durably persisted. If the transaction confirms and the node then crashes, it would lose the ability to enforce its channel state. The fix defers releasing tx_signatures until the corresponding monitor update completes.

  • ● LND #10602 adds a DeleteAttempts RPC to the experimental switchrpc subsystem (see Newsletter #386) to allow external controllers to explicitly delete completed (succeeded or failed, not pending) HTLC attempt records from LND’s attempt store.

  • ● LND #10481 adds a bitcoind miner backend to LND’s integration test framework. Previously, lntest assumed a btcd-based miner even when using bitcoind as the chain backend. This change allows tests to exercise behavior that depends on Bitcoin Core’s mempool and mining policy, including v3 transaction relay and package relay.

  • ● BOLTs #1160 merges the splicing protocol into the Lightning specification, replacing the draft in BOLTs #863 with updated flows and test vectors for edge cases that motivated the rewrite (see Newsletter #246 for discussion when that draft was under active development). Splicing lets peers add or remove funds without closing the channel; negotiation begins from a quiescent state (BOLTs #869, Newsletter #309). The merged BOLT2 text covers interactive construction of the splice transaction, continuing to operate the channel while a splice is unconfirmed, RBF of pending splices, reconnect behavior, splice_locked after sufficient depth, and updated channel announcements.

Want more?

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