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

  • ● Argo: a garbled-circuits scheme with more efficient off-chain computation: Robin Linus posted to Delving Bitcoin about a new paper by Liam Eagen and Ying Tong Lai describing a technique that will enable 1000 times more efficient garbled locks. 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-like constructs on Bitcoin.

  • ● LN-Symmetry update: Gregory Sanders posted an update to Delving Bitcoin about his previous work on LN-Symmetry (see Newsletter #284).

    Sanders rebased his previous proof-of-concept work on the BOLTs specifications and CLN implementation to the latest updates. The updated implementation now works on Bitcoin Inquisition 29.x on signet with TRUC, ephemeral dust, P2A, and 1p1c 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), modified a BOLT draft and created a CLN-based implementation. 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 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.

  • ● Libsecp256k1 0.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, 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 #33822 adds block header support to the libbitcoinkernel API interface (see Newsletter #380). 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.

  • ● Bitcoin Core #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 and #130). While the GUI already enforced this restriction, the RPCs and underlying functions did not. Wallet migration can still restore unnamed wallets. See Newsletter #387 for a bug related to unnamed wallets.

  • ● Core Lightning #8850 removes several deprecated features: option_anchors_zero_fee_htlc_tx, renamed to option_anchors to reflect changes on 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.

  • ● LDK #4349 adds validation for bech32 padding when parsing BOLT12 offers, as specified in BIP173. 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.

  • ● Rust Bitcoin #5470 adds validation to the decoder to reject transactions with zero outputs, as valid Bitcoin transactions must have at least one output.

  • ● Rust Bitcoin #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, a historical vulnerability where an attacker could create transactions with extremely large output values.

  • ● BDK #2037 adds the median_time_past() method to calculate median-time-past (MTP) for CheckPoint structures. MTP, defined in BIP113, is the median timestamp of the previous 11 blocks and is used to validate timelocks. See Newsletter #372 for previous work enabling this.

  • ● BIPs #2076 adds BIP434 which defines a P2P feature message that would allow peers to announce and negotiate support for new features. The idea generalizes BIP339’s mechanism (see Newsletter #87) but instead of requiring a new message type for each feature, BIP434 provides a single, reusable message for announcing and negotiating multiple P2P upgrades. This benefits various proposed P2P use cases, including template sharing. See Newsletter #386 for the mailing list discussion.

  • ● BIPs #1500 adds BIP346 which defines the OP_TXHASH opcode for tapscript that pushes onto the stack a hash digest of specified parts of the spending transaction. This can be used to create covenants and reduce interactivity in multi-party protocols. The opcode generalizes OP_CHECKTEMPLATEVERIFY and, when combined with OP_CHECKSIGFROMSTACK, can emulate SIGHASH_ANYPREVOUT. See Newsletters #185 and #272 for previous discussion.

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 February 3. The discussion is also recorded and will be available from our podcasts page.