This week’s newsletter describes a proposal to allow relay of transactions with zero-value outputs in some cases and summarizes a discussion about preparing LN for the adoption of PTLCs. Also included are our regular sections with a list of recent changes to services and client software, popular questions on the Bitcoin Stack Exchange, and notable changes to popular Bitcoin infrastructure software.

News

• ● Adding a special exception for certain uneconomical outputs: since our description in Newsletter #162, Jeremy Rubin has renewed discussion on the Bitcoin-Dev mailing list about allowing transactions to create outputs with values below the dust limit. The dust limit is a transaction relay policy that nodes use to discourage users from creating UTXOs that don’t make economic sense to spend. UTXOs need to be stored by at least some full nodes until spent, and in some cases be able to be retrieved quickly, so allowing uneconomical outputs may create problems for no good reason.

  However, there may be a use for zero-value outputs in CPFP fee bumping where none of the funds from the transaction being fee bumped can be spent—all the funds used for fee bumping need to come from separate UTXOs, such as in eltoo. Ruben Somsen also provided an example of how zero-fee outputs would be useful for spacechains (a type of one-way pegged sidechain).

  No clear conclusion was reached in the discussion as of this writing.

• ● Preparing LN for PTLCs: Bastien Teinturier started a thread on the Lightning-Dev mailing list about making the minimal set of changes to the LN communication protocol necessary to allow nodes to begin upgrading to using PTLCs. PTLCs are more private than the currently-used HTLCs and use less block space.

  Teinturier is trying to produce a set of changes that can be made at the same time as the proposed option_simplified_update protocol change (see Newsletter #120). A secondary goal is trying to make the communication protocol compatible with the fast-forwards based PTLC protocol described in Newsletter #152. This will allow nodes to upgrade in stages, first to option_simplified_update with HTLCs, then to PTLCs, then to fast forwards.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

• ● Simple Bitcoin Wallet adds taproot sends: SBW version 2.4.22 allows users to send to taproot addresses.

• ● Trezor Suite supports taproot: Trezor announced that the 21.12.2 version of Trezor Suite supports taproot. After downloading the latest client and firmware, users can create a new taproot account.

• ● BlueWallet adds taproot sends: BlueWallet v6.2.14 adds send support for taproot addresses.

• ● Cash App adds taproot sends: As of December 1, 2021, Cash App users can send to bech32m addresses.

• ● Swan adds taproot sends: Swan announced taproot withdrawal (send) support.

• ● Wallet of Satoshi adds taproot sends: Wallet of Satoshi, a mobile Bitcoin and Lightning wallet, announced taproot send support.

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.

• ● What is the script assembly and execution in P2TR spend (spend from Taproot)? Pieter Wuille provides a detailed walk-through of a simplified BIP341 example of constructing a taproot output, spending using the keypath, spending using the scriptpath, and validating spends.

• ● How can I find samples for P2TR transactions on mainnet? Murch provides block explorer links for: the first P2TR transaction, the first transaction with a scriptpath and keypath input, the first transaction with multiple keypath inputs, the first scriptpath 2-of-2 multisig spend, and the first use of the new tapscript opcode OP_CHECKSIGADD.

• ● Does a miner adding transactions to a block while mining reset the block’s PoW? Pieter Wuille explains that mining is progress free. Each hash attempt to solve a block is independent from what work has been done so far, including if new transactions are added to a block currently being mined.

• ● Can schnorr aggregate signatures be nested inside other schnorr aggregate signatures? Pieter Wuille describes the feasibility of a key-aggregation scheme using schnorr signatures, where “keys can be aggregated hierarchically without signers having knowledge about their ‘niece/nephew’ keys”. He notes that MuSig2 was designed to be compatible with nesting and that it could be modified for this use case, although no security proof exists.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

• ● Bitcoin Core #23716 adds a native Python implementation of RIPEMD-160 to Bitcoin Core’s test code. This allows Bitcoin Core to no longer use the RIPEMD-160 function from Python hashlib library which wraps the OpenSSL implementation of RIPEMD-160. Newer versions of OpenSSL no longer provide RIPEMD-160 support by default, requiring it to be enabled separately.

• ● Bitcoin Core #20295 adds a new RPC getblockfrompeer which permits requesting a specific block from a specific peer manually. The intended use is acquisition of stale chaintips for fork monitoring and research purposes.

• ● Bitcoin Core #14707 updates several RPCs to also include bitcoins received via miner coinbase transaction outputs. A new include_immature_coinbase option to the RPCs allows toggling the inclusion of coinbase transactions before they are mature (have 100 confirmations, the earliest they can be spent according to consensus rules).

• ● Bitcoin Core #23486 updates the decodescript RPC to only return the P2SH or P2WSH addresses for a script if that script can be used, respectively, with P2SH or P2WSH.

• ● BOLTs #940 deprecates the announcement and parsing of Tor v2 onions in node_announcements. Rust-Lightning #1204, also merged this week, updates that implementation to follow this updated specification.

• ● BOLTs #918 removes the rate limiting of ping messages. ping messages are mainly used to check if the peer connection is still alive. Prior to this merge ping messages were supposed to be sent at most once every 30 seconds. For many nodes it is useful to send heart beat messages via ping more frequently to assure a high quality of service. As other Lightning messages are not rate limited the 30 seconds rate limit for ping messages was also dropped.

• ● BOLTs #906 adds a new feature bit for the channel_type feature described in Newsletter #165. By adding a bit, it will become easier for future nodes to only choose peers that understand the new feature.

Holiday publication schedule

Happy holidays! This issue is our final regular newsletter for the year. Next week we’ll publish our annual special year-in-review issue. We’ll return to regular publication on Wednesday, January 5th.