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.
● 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_updateprotocol 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_updatewith 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.
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
● 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
hashliblibrary 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
getblockfrompeerwhich 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_coinbaseoption 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).
● 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.
pingmessages are mainly used to check if the peer connection is still alive. Prior to this merge
pingmessages were supposed to be sent at most once every 30 seconds. For many nodes it is useful to send heart beat messages via
pingmore frequently to assure a high quality of service. As other Lightning messages are not rate limited the 30 seconds rate limit for
pingmessages was also dropped.
● BOLTs #906 adds a new feature bit for the
channel_typefeature 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.