This week’s newsletter summarizes an update to the liquidity advertisements specification. Also included are 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

• ● Update to the liquidity ads specification: Lisa Neigut posted to the Lightning-Dev mailing list to announce an update to the specification for liquidity advertisements. That feature, implemented in Core Lightning and currently being worked on for Eclair, allows a node to announce that it is willing to contribute funds to a dual-funded channel. If another node accepts the offer by requesting to open a channel, the requesting node must pay the offering node an upfront fee. This allows a node needing incoming liquidity (e.g., a merchant) to find well-connected peers that can provide that liquidity at a market rate, entirely using open source software and the decentralized LN gossip protocol.

  The updates include a few structural changes plus increased flexibility to the contract duration and forwarding fee ceiling. The post received several replies on the mailing list and additional changes to the specification are expected. Neigut’s post also notes that the current construction of liquidity advertisements and channel announcements makes it theoretically possible to cryptographically prove one case where a party is violating its contract. It’s an open problem to design an actual compact fraud proof that could be used in a bond contract to incentivize contract compliance.

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.

• ● Is the Schnorr digital signature scheme a multisignature interactive scheme, and also not an aggregated non-interactive scheme? Pieter Wuille describes the differences between multisignatures, signature aggregation, key aggregation, and Bitcoin multisig and notes several related schemes including BIP340 schnorr signatures, MuSig2, FROST, and Bellare–Neven 2006.

• ● Is it advisable to operate a release candidate full node on mainnet? Vojtěch Strnad and Murch point out that running Bitcoin Core release candidates on mainnet pose little threat to the Bitcoin network but users of Bitcoin Core’s APIs, wallet, or other features should exercise appropriate caution and testing for their configuration.

• ● What is the relation between nLockTime and nSequence? Antoine Poinsot and Pieter Wuille answer a series of Stack Exchange questions about nLockTime and nSequence including the relationship between the two, the original purpose of nLockTime, the potential values of nSequence and relationship to BIP68 and OP_CHECKLOCKTIMEVERIFY.

• ● What would happen if we provide to OP_CHECKMULTISIG more than threshold number (m) of signatures? Pieter Wuille explains that while this was possible previously, the BIP147 dummy stack element malleability soft fork no longer allows the additional stack element in OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY to be an arbitrary value.

• ● What is “(mempool) policy”? Antoine Poinsot defines the terms policy and standardness in the context of Bitcoin Core and provides a few examples. He also links to Bitcoin Optech’s Waiting for confirmation series on policy.

• ● What does Pay to Contract (P2C) mean? Vojtěch Strnad describes Pay-to-Contract (P2C) and links to the original proposal.

• ● Can a non-segwit transaction be serialized in the segwit format? Pieter Wuille points out that while several older versions of Bitcoin Core unintentionally allowed the extended serialization format for non-segwit transactions, BIP144 specifies non-segwit transactions must use the old serialization format.

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.

• ● Core Lightning 23.11 is a release of the next major version of this LN node implementation. It provides additional flexibility to the rune authentication mechanism, improved backup verification, new and features for plugins.

• ● Bitcoin Core 26.0rc3 is a release candidate for the next major version of the predominant full-node implementation. There’s a testing guide available.

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, and Bitcoin Inquisition.

• ● Rust Bitcoin #2213 amends the weight prediction for P2WPKH inputs processes during fee estimation. Since transactions with high-s signatures are considered non-standard since Bitcoin Core versions 0.10.3 and 0.11.1, transaction building processes can safely assume that any serialized ECDSA signatures will at most take 72 bytes instead of the previously used upper bound of 73 bytes.

• ● BDK #1190 adds a new Wallet::list_output method that retrieves all outputs in the wallet, both spent outputs and unspent outputs. Previously, it was easy to get a list of unspent outputs but difficult to get a list of spent outputs.