This week’s newsletter describes a proposed light client protocol for silent payments, summarizes two new proposed descriptors for taproot, and links to a discussion about whether opcodes with overlapping features should be added in a soft fork. Also included are our regular sections with popular questions and answers from the Bitcoin Stack Exchange, announcements of new releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.

News

  • ● Light client protocol for silent payments: Setor Blagogee posted to Delving Bitcoin to describe a draft specification for a protocol to help lightweight clients receive silent payments (SPs). The addition of a few cryptographic primitives is sufficient to give any wallet software the ability to send SPs, but receiving silent payments requires not only those primitives but also the ability to access information about every SP-compatible onchain transaction. This is easy for full nodes, such as Bitcoin Core, that already process every onchain transaction, but it requires additional features for lightweight clients that typically try to minimize the amount of transaction data they request.

    The basic protocol has a service provider build a per-block index of the public keys that can be used with SPs. Clients download that index and a compact block filter for the same block. Clients compute their local tweak for each key (or set of keys) and determine if the block filter contains a payment to their corresponding tweaked key. If it does, they download additional block-level data that allows them to learn how much they’ve received and how to later spend the payment.

  • ● Raw taproot descriptors: Oghenovo Usiwoma posted to Delving Bitcoin about two new proposed descriptors for constructing taproot spend conditions:

    • rawnode(<hash>) takes the hash of a merkle tree node, whether for an internal node or for leaf node. This allows a wallet or other scanning program to find particular output scripts without knowing exactly what tapscripts they use. This is not safe for receiving money in most situations—an unknown script might be either unspendable or allow a third party to spend funds—but there can be protocols where it is safe.

      Anthony Towns gives an example where Alice wants Bob to be able to inherit her money; for her spending paths, she only gives Bob the raw node hashes; for his inheritance path, she gives him a templated descriptor (perhaps including a timelock that prevents him from spending until a period of time has past). This is safe for Bob because the money isn’t his and it’s good for Alice’s privacy because she doesn’t need to reveal any of her other spend conditions to Bob upfront (although Bob may learn them from Alice’s onchain transactions).

    • rawleaf(<script>,[version]) is similar to the existing raw descriptor for including scripts that can’t be expressed using a templated descriptor. Its main difference is that it includes the ability to indicate a different tapleaf version than the tapscript default specified in BIP342.

    Usiwoma’s post provides an example and links to previous discussion and a reference implementation he has created.

  • ● Should overlapping soft fork proposals be considered mutually exclusive? Pierre Rochard asks if proposed soft forks that can provide much of the same features at a similar cost should be considered mutually exclusive, or whether it would make sense to activate multiple proposals and let developers use whichever alternative they prefer.

    Anthony Towns replies to multiple points, including suggesting that overlapping features by themselves are not a problem but features that aren’t used because everyone prefers an alternative may produce several problems. He suggests anyone who favors a particular proposal test using its features in pre-production software to get a feel for them, especially in comparison to alternative ways the feature can be added to Bitcoin.

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.

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 #29612 updates the serialization format of the UTXO set dump output through the dumptxoutset RPC. This results in a 17.4% space optimization. The loadtxoutset RPC now expects the new format when loading the UTXO set dump file; the old format is no longer supported. See Newsletters #178 and #72 for previous references to dumptxoutset.

  • ● Bitcoin Core #27064 changes the default data directory on Windows from C:\Users\Username\AppData\Roaming\Bitcoin to C:\Users\Username\AppData\Local\Bitcoin on fresh installs only.

  • ● Bitcoin Core #29873 introduces a 10 kvB data weight limit for Topologically Restricted Until Confirmation (TRUC) transactions (v3 transactions) to reduce the potential cost of mitigation against transaction pinning attacks, improve block template construction efficiency, and impose tighter memory limits on certain data structures. V3 transactions are a subset of standard transactions with additional rules designed to allow transaction replacement while minimizing the cost of overcoming transaction-pinning attacks. See Newsletter #289 and #296 for more on v3 transactions.

  • ● Bitcoin Core #30062 adds two new fields, mapped_as and source_mapped_as, to the getrawaddrman RPC, a command that returns information about the network addresses of peer nodes. The new fields return the Autonomous System Number (ASN) mapped to the peer and its source, to provide approximate information about which ISPs control which IP addresses and increase Bitcoin Core’s resistance to eclipse attacks. See Newsletter #52, #83, #101, #290.

  • ● Bitcoin Core #26606 introduces BerkeleyRODatabase, an independent implementation of a Berkeley Database (BDB) file parser that provides read-only access to BDB files. Legacy wallet data can now be extracted without the need for the heavy BDB library, to ease the migration to descriptor wallets. The wallettool’s dump command is changed to use BerkeleyRODatabase.

  • ● BOLTs #1092 cleans up the Lightning Network (LN) specification by removing the unused and no longer supported features initial_routing_sync and option_anchor_outputs. Three features are now assumed to be present in all nodes: var_onion_optin for variable-sized onion messages to relay arbitrary data to specific hops, option_data_loss_protect for nodes to send information about their latest channel state when they reconnect, and option_static_remotekey to allow a node to request that every channel update commit to sending the node’s non-HTLC funds to the same address. The gossip_queries feature for specific gossip requests is changed so that a node that doesn’t support it won’t be queried by other nodes. See Newsletter #259.