This week’s newsletter announces the beta release of a full node supporting utreexo and summarizes a two proposed extensions to BIP119 OP_CHECKTEMPLATEVERIFY. Also included are our regular sections announcing new releases and release candidates and describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Release of utreexod beta: Calvin Kim posted to the Bitcoin-Dev mailing list to announce the beta release of utreexod, a full node with support for utreexo. Utreexo allows a node to store a small commitment to the state of the UTXO set rather than the entire set itself; for example, a minimal commitment can be 32 bytes and the current full set is about 12 GB, making the commitment on the order of about a billion times smaller. To reduce bandwidth, utreexo may store additional commitments, increasing its use of disk space, but still keeping its chainstate roughly on the order of a million times smaller than a traditional full node. A utreexo node that also prunes old blocks can run in a small constant amount of disk space, whereas even pruned regular full nodes can have their chainstate grow beyond the bounds of a device’s storage capacity.

    The release notes posted by Kim indicate that the node is compatible with BDK-based wallets, plus many other wallets through support for Electrum personal server. The node supports transaction relay with extensions to the P2P network protocol for allowing the relay of utreexo proofs. Both regular and bridge utreexo nodes are supported; regular utreexo nodes use the utreexo commitment to save disk space; bridge nodes store the complete UTXO state plus some additional data and can attach utreexo proofs to blocks and transactions created by nodes and wallets that don’t support utreexo yet.

    Utreexo does not require consensus changes and utreexo nodes do not interfere with non-utreexo nodes, although regular utreexo nodes can only peer with other regular and bridge utreexo nodes.

    Kim includes several warnings in his announcement: “the code and protocol is not peer reviewed […] there will be breaking changes […] utreexod is based on btcd [which may have] consensus incompatibilities”.

  • ● BIP119 extensions for smaller hashes and arbitrary data commitments: Jeremy Rubin posted to the Bitcoin-Dev mailing list a proposed BIP to extend the proposed OP_CHECKTEMPLATEVERIFY (OP_CTV) with two additional features:

    • ● Support for HASH160 hashes: these are the hash digests used for P2PKH, P2SH, and P2WPKH addresses. They are 20 bytes compared to the 32-byte hash digests used in the base BIP119 proposal. In naive multiparty protocols, a collision attack against a 20-byte hash can be performed in about 280 brute force operations, which is within reach of a highly motivated attacker. For this reason, modern Bitcoin opcodes typically use 32-byte hash digests. However, security in single-party protocols or well-designed multiparty protocols using 20-byte hashes can be increased to make compromise unlikely in less than about 2160 brute-force operations, allowing those protocols to save about 12 bytes per digest. One case where that might be useful is in implementations of the eltoo protocol (see Newsletter #284).

    • ● Support for additional commitments: OP_CTV only succeeds if it is executed within a transaction that contains inputs and outputs that hash to the same value as a provided hash digest. One of those outputs could be an OP_RETURN output that commits to some data that the script creator wants to be published to the blockchain, such as data necessary to recover LN channel state from a backup. However, putting data in the witness field would be significantly less expensive. The proposed updated form of OP_CTV allows a script creator to require that an additional piece of data from the witness stack be included when the inputs and outputs are hashed. That data will be checked against the hash digest provided by the script creator. This ensures that data is published to the blockchain with minimal use of block weight.

    The proposal has not received any discussion on the mailing list as of this writing.

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.

  • ● LDK v0.0.123 is a release of this popular library for building LN-enabled applications. It includes an update to its settings for trimmed HTLCs, improvements to offers support, and many other improvements.

  • ● LND v0.18.0-beta.rc2 is a release candidate for the next major version of this popular LN node.

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.

  • ● Bitcoin Core #29845 updates several get*info RPCs to change the warnings field from a string to an array of strings so that several warnings can be returned instead of just one.

  • ● Core Lightning #7111 makes the check RPC command available to plugins through the libplugin utility. Usage is also extended by enabling check setconfig which validates that configuration options would be accepted, and the existing check keysend now validates if hsmd would approve the transaction. A pre-initialization message has been added with pre-set HSM development flags. For further references on the check command, see also Newsletters #25 and #47.

  • ● Libsecp256k1 #1518 adds a secp256k1_pubkey_sort function that sorts a set of public keys into a canonical order. This is useful for both MuSig2 and silent payments, and likely many other protocols involving multiple keys.

  • ● Rust Bitcoin #2707 updates the API for tagged hashes introduced as part of taproot to expect the digests in internal byte order by default. Previously, the API expected the hashes in display byte order, which can now be obtained with code like #[hash_newtype(backward)]. For historical reasons, the txid and block identifier hash digests appear inside transactions and blocks in one byte order (internal byte order) but are displayed and called in user interfaces in the reverse order (display byte order). This PR tries to prevent even more hashes from having different byte orders for different circumstances.

  • ● BIPs #1389 adds BIP388 which describes “wallet policies for descriptor wallets”, a templated set of output script descriptors that may be easier for a broad set of wallets to support in both code and their user interface. In particular, descriptors can be challenging to implement on hardware wallets with limited resources and limited screen space. The BIP388 wallet policies allow software and hardware that opts-in to it to make simplifying assumptions about how descriptors will be used; this minimizes the scope of descriptors, reducing the amount of code needed and the number of details that need to be verified by users. Any software needing the full power of descriptors can still use them independently of BIP388. For additional information, see Newsletter #200.

  • ● BIPs #1567 adds BIP387 with new multi_a() and sortedmulti_a() descriptors that provide scripted multisig capabilities within tapscript. Taking an example from the BIP, the descriptor fragment multi_a(k,KEY_1,KEY_2,...,KEY_n) will produce a script such as KEY_1 OP_CHECKSIG KEY_2 OP_CHECKSIGADD ... KEY_n OP_CHECKSIGADD OP_k OP_NUMEQUAL. See also Newsletters #191, #227, and #273.

  • ● BIPs #1525 adds BIP347 which proposes an OP_CAT opcode that could be used in tapscript if it was activated in a soft fork. See also Newsletters #274, #275, and #293.

Newsletter publication date changes

In the coming weeks, Optech will be experimenting with alternative publication dates. Please don’t be surprised if you receive the newsletter a few days early or late. During the brief experiment period, our emailed newsletters will include a tracker to help us determine how many people read the newsletter. You can prevent tracking by disabling the loading of external resources before reading the newsletter. If you desire even more privacy, we recommend subscribing to our RSS feed over an ephemeral Tor connection. We apologize for any inconvenience.