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 (https://bitcoinops.org/en/internal/sources/).

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange (https://bitcoin.stackexchange.com/) 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.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#what-is-meant-by-bitcoin-doesn-t-use-encryption) What is meant by “Bitcoin doesn’t use encryption”? (https://bitcoin.stackexchange.com/a/130576) Pieter Wuille distinguishes encryption for purposes concealing data from unauthorized parties (which Bitcoin’s ECDSA cannot be used for) from the digital signatures Bitcoin uses for verification and authentication.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#when-and-why-did-bitcoin-script-shift-to-a-commit-reveal-structure) When and why did Bitcoin Script shift to a commit–reveal structure? (https://bitcoin.stackexchange.com/a/130580) User bca-0353f40e explains the evolution from Bitcoin’s original approach of users paying directly to public keys toward P2PKH and then to P2SH, segwit (https://bitcoinops.org/en/topics/segregated-witness/) and taproot (https://bitcoinops.org/en/topics/taproot/) approaches, where spending conditions are committed to in the output and only revealed when spent.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#does-p2tr-ms-taproot-m-of-n-multisig-leak-public-keys) Does P2TR-MS (Taproot M-of-N multisig) leak public keys? (https://bitcoin.stackexchange.com/a/130574) Murch confirms that a single-leaf taproot scriptpath multisig exposes all eligible public keys on spend since OP_CHECKSIG and OP_CHECKSIGADD both require that the public key corresponding to the signature is present.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#does-op-checksigfromstack-intentionally-allow-cross-utxo-signature-reuse) Does OP_CHECKSIGFROMSTACK intentionally allow cross-UTXO signature reuse? (https://bitcoin.stackexchange.com/a/130598) User bca-0353f40e explains that OP_CHECKSIGFROMSTACK (https://bitcoinops.org/en/topics/op_checksigfromstack/) (BIP348 (https://github.com/bitcoin/bips/blob/master/bip-0348.md)) deliberately does not bind signatures to specific inputs which allows CSFS to be combined with other convenant (https://bitcoinops.org/en/topics/covenants/) opcodes to enable re-bindable signatures, the mechanism underlying LN-Symmetry (https://bitcoinops.org/en/topics/eltoo/).

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.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#bitcoin-core-28-4) Bitcoin Core 28.4 (https://bitcoincore.org/en/2026/03/18/release-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 (https://bitcoincore.org/en/releases/28.4/) for details.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#core-lightning-26-04rc1) Core Lightning 26.04rc1 (https://github.com/ElementsProject/lightning/releases/tag/v26.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 (https://github.com/bitcoin/bitcoin), Core Lightning (https://github.com/ElementsProject/lightning), Eclair (https://github.com/ACINQ/eclair), LDK (https://github.com/lightningdevkit/rust-lightning), LND (https://github.com/lightningnetwork/lnd/), libsecp256k1 (https://github.com/bitcoin-core/secp256k1), Hardware Wallet Interface (HWI) (https://github.com/bitcoin-core/HWI), Rust Bitcoin (https://github.com/rust-bitcoin/rust-bitcoin), BTCPay Server (https://github.com/btcpayserver/btcpayserver/), BDK (https://github.com/bitcoindevkit/bdk), Bitcoin Improvement Proposals (BIPs) (https://github.com/bitcoin/bips/), Lightning BOLTs (https://github.com/lightning/bolts), Lightning BLIPs (https://github.com/lightning/blips), Bitcoin Inquisition (https://github.com/bitcoin-inquisition/bitcoin), and BINANAs (https://github.com/bitcoin-inquisition/binana).

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#bitcoin-core-33259) Bitcoin Core #33259 (https://github.com/bitcoin/bitcoin/issues/33259) adds a backgroundvalidation field to the getblockchaininfo RPC response for nodes using assumeUTXO (https://bitcoinops.org/en/topics/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.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#bitcoin-core-33414) Bitcoin Core #33414 (https://github.com/bitcoin/bitcoin/issues/33414) enables Tor proof of work defenses (https://tpo.pages.torproject.net/onion-services/ecosystem/technology/security/pow/) 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.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#bitcoin-core-34846) Bitcoin Core #34846 (https://github.com/bitcoin/bitcoin/issues/34846) adds the functions btck_transaction_get_locktime and btck_transaction_input_get_sequence to the libbitcoinkernel C API (see Newsletter #380 (https://bitcoinops.org/en/newsletters/2025/11/14/#bitcoin-core-30595)) for accessing timelock (https://bitcoinops.org/en/topics/timelocks/) fields: a transaction’s nLockTime and an input’s nSequence. This allows checking BIP54 (https://github.com/bitcoin/bips/blob/master/bip-0054.md) (consensus cleanup (https://bitcoinops.org/en/topics/consensus-cleanup-soft-fork/)) rules such as coinbase nLockTime constraints without manually deserializing the transaction (other BIP54 rules, such as sigops limits, still require separate handling).

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#core-lightning-8450) Core Lightning #8450 (https://github.com/ElementsProject/lightning/issues/8450) extends CLN’s splice (https://bitcoinops.org/en/topics/splicing/) 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.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#core-lightning-8856) Core Lightning #8856 (https://github.com/ElementsProject/lightning/issues/8856) and #8857 (https://github.com/ElementsProject/lightning/issues/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 (https://bitcoinops.org/en/topics/splicing/) transactions manually with the experimental dev-splice RPC.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#eclair-3247) Eclair #3247 (https://github.com/ACINQ/eclair/issues/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.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#ldk-4472) LDK #4472 (https://github.com/lightningdevkit/rust-lightning/issues/4472) fixes a potential funds-loss scenario during channel funding and splicing (https://bitcoinops.org/en/topics/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.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#lnd-10602) LND #10602 (https://github.com/lightningnetwork/lnd/issues/10602) adds a DeleteAttempts RPC to the experimental switchrpc subsystem (see Newsletter #386 (https://bitcoinops.org/en/newsletters/2026/01/02/#lnd-9489)) to allow external controllers to explicitly delete completed (succeeded or failed, not pending) HTLC (https://bitcoinops.org/en/topics/htlc/) attempt records from LND’s attempt store.

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#lnd-10481) LND #10481 (https://github.com/lightningnetwork/lnd/issues/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 (https://bitcoinops.org/en/topics/version-3-transaction-relay/) and package relay (https://bitcoinops.org/en/topics/package-relay/).

• ● (https://bitcoinops.org/en/newsletters/2026/03/27/#bolts-1160) BOLTs #1160 (https://github.com/lightning/bolts/issues/1160) merges the splicing (https://bitcoinops.org/en/topics/splicing/) protocol into the Lightning specification, replacing the draft in BOLTs #863 (https://github.com/lightning/bolts/issues/863) with updated flows and test vectors for edge cases that motivated the rewrite (see Newsletter #246 (https://bitcoinops.org/en/newsletters/2023/04/12/#splicing-specification-discussions) 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 (https://github.com/lightning/bolts/issues/869), Newsletter #309 (https://bitcoinops.org/en/newsletters/2024/06/28/#bolts-869)). The merged BOLT2 text covers interactive construction of the splice transaction, continuing to operate the channel while a splice is unconfirmed, RBF (https://bitcoinops.org/en/topics/replace-by-fee/) of pending splices, reconnect behavior, splice_locked after sufficient depth, and updated channel announcements (https://bitcoinops.org/en/topics/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 (https://riverside.fm/studio/bitcoin-optech) at 16:30 UTC on March 31. The discussion is also recorded and will be available from our podcasts (https://bitcoinops.org/en/podcast/) page.