This week’s newsletter summarizes several recent discussions about a Lisp dialect for Bitcoin scripting and includes our regular sections with descriptions of popular questions and answers on the Bitcoin Stack Exchange, announcements of new releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure projects.

News

• ● Lisp dialect for Bitcoin scripting: Anthony Towns made several posts about a continuation of his work on creating a Lisp dialect for Bitcoin that could be added to Bitcoin in a soft fork.

  • ● bll, symbll, bllsh: Towns notes that he spent a long time thinking about advice from Chia Lisp developer Art Yerkes about ensuring a good mapping between high-level code (what programmers typically write) and low-level code (what actually gets run, typically created from high-level code by compilers). He decided to take a miniscript-like approach where “you treat the high-level language as a friendly variation of the low-level language (as miniscript does with script)”. The result is two languages and a tool:

    • ● Basic Bitcoin Lisp language (bll) is the low-level language that could be added to Bitcoin in a soft fork. Towns says bll is similar to BTC Lisp as of his last update (see Newsletter #294).

    • ● Symbolic bll (symbll) is the high-level language that is converted into bll. It should be relatively easy for anyone already familiar with functional programming.

    • ● Bll shell (bllsh) is a REPL that allows a user to test scripts in bll and symbll, compile from symbll to bll, and execute code with debugging capabilities.

  • ● Implementing quantum-safe signatures in symbll versus GSR: Towns links to a Twitter post by Jonas Nick about implementing Winternitz One Time Signatures (WOTS+) using existing opcodes and the opcodes specified in Rusty Russell’s great script restoration (GSR) proposal. Towns then compares implementing WOTS using symbll in bllsh. This reduces the amount of data that would need to be placed onchain by at least 83% and potentially by more than 95%. That could allow the use of quantum-safe signatures at a cost only 30x greater than P2WPKH outputs.

  • ● Flexible coin earmarks: Towns describes a generic construction compatible with symbll (and probably Simplicity) that allows partitioning a UTXO into specific amounts and spending conditions. If a spending condition is fulfilled, the associated amount can be spent and the remaining value from the UTXO is returned to a new UTXO with the remaining conditions. An alternative condition may also be satisfied to allow spending the entire UTXO; for example, this could allow all parties to agree to update some of the conditions. This is a flexible type of covenant mechanism, similar to Towns’s previous proposal for OP_TAP_LEAF_UPDATE_VERIFY (TLUV, see Newsletter #166), but Towns has written previously that he thinks covenants is “not an accurate or useful term”.

    Several examples for how these flexible coin earmarks can be used are provided, including improvements in the security and usability of LN channels (including LN-Symmetry-based channels), an alternative to the BIP345 version of vaults, and a payment pool design similar to that contemplated for use with TLUV but that avoids the problems that proposal had with x-only public keys.

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.

• ● How does ColliderScript improve Bitcoin and what features does it enable? Victor Kolobov lists potential uses for ColliderScript (see Newsletter #330 and Podcast #330) including covenants, vaults, emulation of CSFS, and validity rollups (see Newsletter #222) while noting the high computational costs of such transactions.

• ● Why do standardness rules limit transaction weight? Murch provides arguments for and against Bitcoin Core’s standardness weight limits and outlines how economic demand for larger transactions could erode the effectiveness of the policy.

• ● Is the scriptSig spending an PayToAnchor output expected to always be empty? Pieter Wuille points out that because of how pay-to-anchor (P2A) outputs are constructed, they must adhere to segwit spending conditions, including an empty scriptSig.

• ● What happens to the unused P2A outputs? Instagibbs notes that unused P2A outputs will eventually be swept when the block inclusion feerate drops low enough to make a sweep worth it, removing them from the UTXO set. He goes on to reference the recently-merged ephemeral dust PR that allows a single below-dust-threshold output in a zero-fee transaction provided a child transaction immediately spends it.

• ● Why doesn’t Bitcoin’s PoW algorithm use a chain of lower-difficulty hashes? Pieter Wuille and Vojtěch Strnad describe the mining centralization pressure that would happen if the progress-free property of Bitcoin’s mining was violated with such an approach.

• ● Clarification on false value in Script Pieter Wuille specifies the three values that evaluate to false in Bitcoin Script: an empty array, an array of 0x00 bytes, and an array of 0x00 bytes with a 0x80 at the end. He notes that all other values are evaluated as true.

• ● What is this strange microtransaction in my wallet? Vojtěch Strnad explains the mechanics of an address poisoning attack and ways to mitigate such attacks.

• ● Are there any UTXOs that can not be spent? Pieter Wuille provides two examples of outputs that are unspendable regardless of the breaking of cryptographic assumptions: OP_RETURN outputs and outputs with a scriptPubKey longer than 10,000 bytes.

• ● Why was BIP34 not implemented via the coinbase tx’s locktime or nSequence? Antoine Poinsot follows up to this older question to point out that the coinbase transaction’s nLockTime value cannot be set to the current block height because the locktime represents the last block at which a transaction is invalid.

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 24.11rc2 is a release candidate for the next major version of this popular LN implementation.

• ● BDK 0.30.0 is a release of this library for building wallets and other Bitcoin-enabled applications. It includes several minor bug fixes and prepares for the anticipated upgrade to the version 1.0 of the library.

• ● LND 0.18.4-beta.rc1 is a release candidate for a minor version of this popular LN implementation.

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 #31122 implements a changeset interface for the mempool, allowing a node to compute the impact of a proposed set of changes on the state of the mempool. For example, checking whether ancestor/descendant/TRUC (and future cluster) limits are violated when a transaction or a package is accepted, or determining whether an RBF fee bump improves the state of the mempool. This PR is part of the cluster mempool project.

• ● Core Lightning #7852 restores backwards compatibility with versions prior to 24.08 for the pyln-client plugin (a Python client library) by reintroducing a description field.

• ● Core Lightning #7740 improves the minimum cost flow (MCF) solver of the askrene (see Newsletter #316) plugin by providing an API that abstracts the complexity of MCF solving to allow easier integration of newly added graph-based flow computation algorithms. The solver adopts the same channel cost function linearization as renepay(see Newsletter #263), which improves pathfinding reliability, and introduces support for customizable units beyond msats, allowing greater scalability for large payments. This PR adds the simple_feasibleflow, get_augmenting_flow, augment_flow, and node_balance methods to improve the efficiency of flow calculations.

• ● Core Lightning #7719 achieves interoperability with Eclair for splicing, allowing splices to be executed between the two implementations. This PR introduces several changes to align with Eclair’s implementation including support for rotating remote funding keys, adding batch_size for commitment-signed messages, preventing transmission of previous funding transactions due to packet size limits, removing blockhashes from messages, and adjusting pre-set funding output balances.

• ● Eclair #2935 adds a notification to the node operator in the event of a channel force close initiated by a channel peer.

• ● LDK #3137 adds support for accepting peer-initiated dual-funded channels, although funding or creating such channels is not yet supported. If manually_accept_inbound_channels is set to false, channels are automatically accepted, while the ChannelManager::accept_inbound_channel() function allows manual acceptance. A new channel_negotiation_type field is introduced to distinguish between inbound requests for dual-funded and non-dual-funded channels. Zero-conf dual-funded channels and RBF fee bumping of funding transactions are not supported.

• ● LND #8337 introduces the protofsm package, a reusable framework for creating event-driven protocol finite state machines (FSMs) in LND. Instead of writing boilerplate code to handle states, transitions, and events, developers can define the states, what triggers events, and the rules for moving between them, and the State interface will encapsulate behavior, handle events, and determine terminal states, while daemon adapters handle side effects like broadcasting transactions and sending peer messages.