This week’s newsletter summarizes a more efficient approach to garbled circuits and links to an LN-Symmetry update. Also included are our regular sections with selected questions and answers from the Bitcoin Stack Exchange, announcements of new software releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.

News

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#argo-a-garbled-circuits-scheme-with-more-efficient-off-chain-computation) Argo: a garbled-circuits scheme with more efficient off-chain computation: Robin Linus posted (https://delvingbitcoin.org/t/argo-a-garbled-circuits-scheme-for-1000x-more-efficient-off-chain-computation/2210) to Delving Bitcoin about a new paper (https://eprint.iacr.org/2026/049.pdf) by Liam Eagen and Ying Tong Lai describing a technique that will enable 1000 times more efficient garbled locks (https://bitcoinops.org/en/newsletters/2025/06/20/#improvements-to-bitvm-style-contracts). The new technique uses a MAC (message authentication code) that encodes the wires of a garbled circuit as EC (elliptic curve) points. The MAC is designed to be homomorphic, enabling many operations within the garbled circuit to be represented directly as operations on EC points. The key improvement is that Argo works over arithmetic circuits, in contrast to binary circuits. With an binary circuit, millions of binary gates are needed to represent a curve point multiplication, whereas with this arithmetic circuit, you only need a single arithmetic gate. The current paper is the first of several pieces needed to apply this technique to BitVM (https://bitcoinops.org/en/topics/acc/)-like constructs on Bitcoin.

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#ln-symmetry-update) LN-Symmetry update: Gregory Sanders posted (https://delvingbitcoin.org/t/ln-symmetry-project-recap/359/17) an update to Delving Bitcoin about his previous work on LN-Symmetry (https://bitcoinops.org/en/topics/eltoo/) (see Newsletter #284 (https://bitcoinops.org/en/newsletters/2024/01/10/#ln-symmetry-research-implementation)).

Sanders rebased his previous proof-of-concept work on the

BOLTs specifications (https://github.com/instagibbs/bolts/tree/eltoo_trucd) and CLN implementation (https://github.com/instagibbs/lightning/tree/2026-01-eltoo_rebased) to the latest updates. The updated implementation now works on Bitcoin Inquisition (https://github.com/bitcoin-inquisition/bitcoin) 29.x on signet (https://bitcoinops.org/en/topics/signet/) with TRUC (https://bitcoinops.org/en/topics/version-3-transaction-relay/), ephemeral dust, P2A (https://bitcoinops.org/en/topics/ephemeral-anchors/), and 1p1c package relay (https://bitcoinops.org/en/topics/package-relay/). It supports cooperative channel closure, fixes a crash that prevented the node from restarting correctly, and expands test coverage. Sanders asked other developers to test his new proof-of-concept on signet with Bitcoin Inquisition.

Sanders also leveraged LLM capabilities to migrate his work from APO to

OP_TEMPLATEHASH+OP_CSFS+IK (see Newsletter #365 (https://bitcoinops.org/en/newsletters/2025/08/01/#taproot-native-op-templatehash-proposal)), modified a BOLT draft (https://github.com/instagibbs/bolts/tree/2026-01-eltoo_th) and created a CLN-based implementation (https://github.com/instagibbs/lightning/commits/2026-01-eltoo_templatehash). However, Sanders added that since OP_TEMPLATEHASH is not yet live on Bitcoin Inquisition, this update can only be tested in regtest.

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/01/30/#what-is-stored-in-dbcache-and-with-what-priority) What is stored in dbcache and with what priority? (https://bitcoin.stackexchange.com/a/130376) Murch describes the purpose of the dbcache data structure as an in-memory cache for the a subset of entire UTXO set and goes on to detail its behavior.

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#can-one-do-a-coinjoin-in-shielded-csv) Can one do a coinjoin in Shielded CSV? (https://bitcoin.stackexchange.com/a/130364) Jonas Nick points out that the Shielded CSV protocol doesn’t support coinjoins (https://bitcoinops.org/en/topics/coinjoin/) currently, but that client-side validation (https://bitcoinops.org/en/topics/client-side-validation/) protocols do not inherently preclude such functionality.

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#in-bitcoin-core-how-to-use-tor-for-broadcasting-new-transactions-only) In Bitcoin Core, how to use Tor for broadcasting new transactions only? (https://bitcoin.stackexchange.com/a/99442) Vasil Dimov follows up to this older question pointing out that with the new privatebroadcast option (see Newsletter #388 (https://bitcoinops.org/en/newsletters/2026/01/16/#bitcoin-core-29415)), Bitcoin Core can broadcast transactions through short-lived privacy network (https://bitcoinops.org/en/topics/anonymity-networks/) connections.

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#brassard-hoyer-tapp-bht-algorithm-and-bitcoin-bip360) Brassard-Høyer-Tapp (BHT) algorithm and Bitcoin (BIP360) (https://bitcoin.stackexchange.com/a/130431) User bca-0353f40e explains that the capability for a collision attack on multisignature (https://bitcoinops.org/en/topics/multisignature/) addresses using the Brassard-Høyer-Tapp (BHT) quantum (https://bitcoinops.org/en/topics/quantum-resistance/) algorithm to diminish SHA256 security would not affect addresses created before the capability.

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#why-does-bithash-alternate-sha256-and-ripmed160) Why does BitHash alternate sha256 and ripmed160? (https://bitcoin.stackexchange.com/a/130373) Sjors Provoost outlines the rationale around BitVM3 (https://bitcoinops.org/en/topics/acc/)’s BitHash function, a hash function tailored for Bitcoin’s Script language.

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/01/30/#libsecp256k1-0-7-1) Libsecp256k1 0.7.1 (https://github.com/bitcoin-core/secp256k1/releases/tag/v0.7.1) is a maintenance release of this library for Bitcoin-related cryptographic operations which includes a security improvement that increases the number of cases where the library attempts to clear secrets from the stack. It also introduces a new unit test framework and some build system changes.

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/01/30/#bitcoin-core-33822) Bitcoin Core #33822 (https://github.com/bitcoin/bitcoin/issues/33822) adds block header support to the libbitcoinkernel API interface (see Newsletter #380 (https://bitcoinops.org/en/newsletters/2025/11/14/#bitcoin-core-30595)). A new btck_BlockHeader type and its associated methods enable creating, copying, and destroying headers, as well as fetching header fields such as hash, previous hash, timestamp, difficulty target, version and nonce. A new btck_chainstate_manager_process_block_header() method validates and processes block headers without requiring the full block, and btck_chainstate_manager_get_best_entry() returns the block tree entry with the most cumulative proof-of-work.

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#bitcoin-core-34269) Bitcoin Core #34269 (https://github.com/bitcoin/bitcoin/issues/34269) disallows creating or restoring unnamed wallets when using the createwallet and restorewallet RPCs, as well as the wallet tool’s create and createfromdump commands (see Newsletters #45 (https://bitcoinops.org/en/newsletters/2019/05/07/#new-wallet-tool) and #130 (https://bitcoinops.org/en/newsletters/2021/01/06/#bitcoin-core-19137)). While the GUI already enforced this restriction, the RPCs and underlying functions did not. Wallet migration can still restore unnamed wallets. See Newsletter #387 (https://bitcoinops.org/en/newsletters/2026/01/09/#bitcoin-core-wallet-migration-bug) for a bug related to unnamed wallets.

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#core-lightning-8850) Core Lightning #8850 (https://github.com/ElementsProject/lightning/issues/8850) removes several deprecated features: option_anchors_zero_fee_htlc_tx, renamed to option_anchors to reflect changes on anchor outputs (https://bitcoinops.org/en/topics/anchor-outputs/), the decodepay RPC (replaced by decode), the tx and txid fields in the close command response (replaced by txs and txids), and estimatefeesv1, the original response format used by the bcli plugin to return fee estimates (https://bitcoinops.org/en/topics/fee-estimation/).

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#ldk-4349) LDK #4349 (https://github.com/lightningdevkit/rust-lightning/issues/4349) adds validation for bech32 (https://bitcoinops.org/en/topics/bech32/) padding when parsing BOLT12 offers (https://bitcoinops.org/en/topics/offers/), as specified in BIP173 (https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki). Previously, LDK would accept offers with invalid padding, whereas other implementations, such as Lightning-KMP and Eclair, would correctly reject them. A new InvalidPadding error variant is added to the Bolt12ParseError enum.

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#rust-bitcoin-5470) Rust Bitcoin #5470 (https://github.com/rust-bitcoin/rust-bitcoin/issues/5470) adds validation to the decoder to reject transactions with zero outputs, as valid Bitcoin transactions must have at least one output.

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#rust-bitcoin-5443) Rust Bitcoin #5443 (https://github.com/rust-bitcoin/rust-bitcoin/issues/5443) adds validation on the decoder to reject transactions where the sum of the output values exceeds MAX_MONEY (21 million bitcoin). This check is related to CVE-2010-5139 (https://bitcoinops.org/en/topics/cve/), a historical vulnerability where an attacker could create transactions with extremely large output values.

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#bdk-2037) BDK #2037 (https://github.com/bitcoindevkit/bdk/issues/2037) adds the median_time_past() method to calculate median-time-past (MTP) for CheckPoint structures. MTP, defined in BIP113 (https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki), is the median timestamp of the previous 11 blocks and is used to validate timelocks (https://bitcoinops.org/en/topics/timelocks/). See Newsletter #372 (https://bitcoinops.org/en/newsletters/2025/09/19/#bdk-1582) for previous work enabling this.

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#bips-2076) BIPs #2076 (https://github.com/bitcoin/bips/issues/2076) adds BIP434 (https://github.com/bitcoin/bips/blob/master/bip-0434.md) which defines a P2P feature message that would allow peers to announce and negotiate support for new features. The idea generalizes BIP339 (https://github.com/bitcoin/bips/blob/master/bip-0339.mediawiki)’s mechanism (see Newsletter #87 (https://bitcoinops.org/en/newsletters/2020/03/04/#improving-feature-negotiation-between-full-nodes-at-startup)) but instead of requiring a new message type for each feature, BIP434 (https://github.com/bitcoin/bips/blob/master/bip-0434.md) provides a single, reusable message for announcing and negotiating multiple P2P upgrades. This benefits various proposed P2P use cases, including template sharing (https://bitcoinops.org/en/newsletters/2025/08/08/#peer-block-template-sharing-to-mitigate-problems-with-divergent-mempool-policies). See Newsletter #386 (https://bitcoinops.org/en/newsletters/2026/01/02/#peer-feature-negotiation) for the mailing list discussion.

• ● (https://bitcoinops.org/en/newsletters/2026/01/30/#bips-1500) BIPs #1500 (https://github.com/bitcoin/bips/issues/1500) adds BIP346 (https://github.com/bitcoin/bips/blob/master/bip-0346.md) which defines the OP_TXHASH opcode for tapscript (https://bitcoinops.org/en/topics/tapscript/) that pushes onto the stack a hash digest of specified parts of the spending transaction. This can be used to create covenants (https://bitcoinops.org/en/topics/covenants/) and reduce interactivity in multi-party protocols. The opcode generalizes OP_CHECKTEMPLATEVERIFY (https://bitcoinops.org/en/topics/op_checktemplateverify/) and, when combined with OP_CHECKSIGFROMSTACK (https://bitcoinops.org/en/topics/op_checksigfromstack/), can emulate SIGHASH_ANYPREVOUT (https://bitcoinops.org/en/topics/sighash_anyprevout/). See Newsletters #185 (https://bitcoinops.org/en/newsletters/2022/02/02/#composable-alternatives-to-ctv-and-apo) and #272 (https://bitcoinops.org/en/newsletters/2023/10/11/#specification-for-op-txhash-proposed) for previous discussion.