This week’s newsletter summarizes a post about trustless onchain betting for potential soft forks and links to a detailed overview of Chia Lisp for Bitcoiners. Also included are our regular sections summarizing a Bitcoin Core PR Review Club meeting, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Trustless onchain betting on potential soft forks: ZmnSCPxj posted to Delving Bitcoin a protocol for giving control over a UTXO to a party that correctly predicts whether or not a particular soft fork will activate. For example, Alice thinks a particular soft fork will activate and she’s interested in acquiring more bitcoins; Bob is also interested in acquiring more bitcoins but does not think that fork will activate. They agree to combine some amount of their bitcoins, at a ratio they both agree upon (e.g. 1:1), so that Alice receives all of the combined bitcoins if the fork activates by a certain time and Bob receives all of the combined bitcoins if it does not. If, before the deadline, a persistent chainsplit occurs where one chain activates the fork and the other forbids it, Alice receives the combined bitcoins on the activated chain and Bob receives the combined bitcoins on the activation-forbidden chain.

    The basic idea has been proposed before (example) but ZmnSCPxj’s version deals with the specifics expected for at least one potential future soft fork, OP_CHECKTEMPLATEVERIFY. ZmnSCPxj also briefly considers the challenges of generalizing the construction to other proposed soft forks, particularly those that upgrade an OP_SUCCESSx opcode.

  • ● Overview of Chia Lisp for Bitcoiners: Anthony Towns posted to Delving Bitcoin a detailed overview of the Lisp variant used by the Chia cryptocurrency. Towns has previously proposed a soft fork introduction of a Lisp-based scripting language for Bitcoin (see Newsletter #191). Anyone interested in the topic is strongly encouraged to read his post.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Re enable OP_CAT is a PR by Armin Sabouri (GitHub 0xBEEFCAF3) that reintroduces the OP_CAT opcode but only on signet Bitcoin Inquisition and only for tapscript (taproot script). Satoshi Nakamoto disabled this opcode in 2010, probably out of an overabundance of caution. The operation replaces the top two elements on the script evaluation stack with the concatenation of those elements.

The motivations for OP_CAT were not discussed.

  • What are the various conditions under which the execution of OP_CAT may result in failure?

    Fewer than 2 items on the stack, resulting item is too large, disallowed by script verify flags (for example, the soft fork is not activated yet), and appears in a non-taproot script (witness version 0 or legacy). ➚

  • OP_CAT redefines one of the OP_SUCCESSx opcodes. Why doesn’t it redefine one of the OP_NOPx opcodes (which have also been used to implement soft fork upgrades in the past)?

    Both OP_SUCCESSx and OP_NOPx opcodes can be redefined to implement soft forks because they restrict the validation rules (they always succeed while the redefined opcodes may fail). Since script execution continues following an OP_NOP, redefined OP_NOP opcodes can’t affect the execution stack (otherwise scripts that used to fail could succeed, which would loosen the rules). Redefined OP_SUCCESS opcodes can affect the stack, because OP_SUCCESS immediately terminates the script (successfully). Since OP_CAT needs to affect the stack, it can’t redefine one of the OP_NOP opcodes. ➚

  • This PR adds both SCRIPT_VERIFY_OP_CAT and SCRIPT_VERIFY_DISCOURAGE_OP_CAT. Why are both needed?

    It allows the soft fork to be phased in. First both are set to true (consensus-enabled but not relayed or mined) until most network nodes are upgraded. Then SCRIPT_VERIFY_DISCOURAGE_OP_CAT is set to false to enable actual usage. If the Bitcoin Inquisition experiment later fails, the process can be run in reverse. If both are set to false, OP_CAT is just OP_SUCCESS. ➚

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 v24.02.1 is a minor update to this LN node containing “a few minor fixes [and] improvements in the cost function of the routing algorithm.”

  • ● Bitcoin Core 26.1rc1 is a release candidate for a maintenance release of the network’s predominant full node implementation.

  • ● Bitcoin Core 27.0rc1 is a release candidate for the next major version of the network’s predominant full node 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, Bitcoin Inquisition, and BINANAs.

  • ● LND #8136 updates the EstimateRouteFee RPC to accept an invoice and a timeout. A route for paying the invoice will be selected and a payment probe will be sent. If the probe successfully completes before the timeout is reached, the cost of using the chosen route will be returned. Otherwise, an error will be returned.

  • ● LND #8499 makes significant changes to the Type-Length-Value (TLV) types used for simple taproot channels in order to improve LND’s API for it. We aren’t aware of any other LN implementations currently using simple taproot channels, but if any are using it, be aware that this may constitute a breaking change.

  • ● LDK #2916 adds a simple API for converting a payment preimage into a payment hash. An LN invoice includes a payment hash; to claim a payment, the ultimate receiver releases the preimage corresponding to that hash (and each hop along the path uses the preimage it receives from its downstream peer to claim the payment from its upstream peer). Since a hash can be derived from a preimage (but not vice versa), receivers and forwarding nodes may only store the preimage. This API allows them to easily derive the hash on demand.