This week’s newsletter summarizes an analysis of several proposals for upgrading LN channels without closing and reopening them, discusses challenges in ensuring pool miners are paid appropriately, links to a discussion about safely using PSBTs for communicating information related to silent payments, announces a proposed BIP for miniscript, and summarizes a proposal for using frequent rebalancing of an LN channel to simulate a price futures contract. Also included are our regular sections summarizing changes to services and client software, announcing new releases and release candidates, and summarizing notable changes to popular Bitcoin infrastructure software.

News

• ● Upgrading existing LN channels: Carla Kirk-Cohen posted to Delving Bitcoin a summary and analysis of existing proposals for upgrading existing LN channels to support new features. She examines a variety of different cases, such as:

  • ● Changing parameters: currently, some channel settings are negotiated between parties and cannot be changed during the lifespan of the channel. Parameter updates would allow renegotiation at subsequent times. For example, nodes might want to change the number of satoshis at which they begin trimming HTLCs or the amount of channel reserve they expect their counterparty to maintain to disincentivize closing in an old state.

  • ● Updating commitments: LN commitment transactions allow an individual to put the current channel state onchain. Commitment upgrades can allow switching to anchor outputs and v3 transactions in P2WSH-based channels, and for simple taproot channels to switch to using PTLCs.

  • ● Replacing funding: LN channels are anchored onchain in a funding transaction, the output of which is spent offchain repeatedly as the commitment transaction. Originally all LN funding transactions used a P2WSH output; however, newer features such as PTLCs require funding transactions to use P2TR outputs.

  Kirk-Cohen compares three previously proposed ideas for upgrading channels:

  • ● Dynamic commitments: as described in a draft specification, this allows changing almost all channel parameters and also provides a generalized path for upgrading funding and commitment transactions using a new “kickoff” transaction.

  • ● Splice to upgrade: this idea allows a splice transaction that would already necessarily update a channel’s onchain funding to change the type of funding used as well as, optionally, its commit transaction format. It doesn’t deal directly with changing channel parameters.

  • ● Upgrade on re-establish: also described in a draft specification, this allows changing many channel parameters any time two nodes re-establish a data connection. It doesn’t deal directly with funding and commitment transaction upgrades.

  With all the options presented, Kirk-Cohen compares them in a table listing their onchain costs, upsides, and downsides; she also compares them against the onchain costs of not making any upgrades. She draws several conclusions, including: “I think that it makes sense to start work on [both] parameter [and] commitment upgrades via dynamic commitments, independently of how we choose to go about upgrading to taproot channels. This gives us the ability to upgrade to option_zero_fee_htlc_tx anchor channels, and provides a commitment format upgrade mechanism that can be used to get us to V3 channels (once specified).”

• ● Challenges in rewarding pool miners: Ethan Tuttle posted to Delving Bitcoin to suggest that mining pools could reward miners with ecash tokens proportionate to the number of shares they mined. The miners could then immediately sell or transfer the tokens, or they could wait for the pool to mine a block, at which point the pool would exchange the tokens for satoshis.

  Both criticisms and suggestions of the idea were posted. We found especially insightful a reply by Matt Corallo where he describes an underlying problem: there are no standardized payment methods implemented by large pools that allow pool miners to calculate their payouts over short intervals. Two commonly used payout types are:

  • ● Pay per share (PPS): this pays a miner proportionately to the amount of work they contributed even if a block isn’t found. Calculating the proportionate payout for the block subsidy is easy, but calculating it for transaction fees is more complicated. Corallo notes that most pools appear to be using an average of the fees collected during the day the share was created, meaning the amount paid per share can’t be calculated until a day after the share was mined. Additionally, many pools may tweak the fee averages in a way that varies by pool.

  • ● Pay per last n shares (PPLNS): rewards miners for shares found near the time the pool finds a block. However, a miner can only be sure that a pool found a block if the miner themselves found it. There’s no way (in the short term) for a typical miner to know the pool is providing them with a correct payout.

  This lack of information means miners won’t quickly switch to a different pool if their main pool begins cheating them of payments. Stratum v2 doesn’t fix this, although candid pools can use a standardized message to tell miners that they’re going to cease paying for new shares. Corallo links to a proposal for Stratum v2 to allow miners to verify that all of their shares are accounted for in payouts, which may at least allow miners to detect if they aren’t being paid correctly after a longer period (hours to days).

  Discussion was ongoing at the time of writing.

• ● Discussion about PSBTs for silent payments: Josie Baker started a discussion on Delving Bitcoin about PSBT extensions for silent payments (SPs), citing a draft specification by Andrew Toth. PSBTs for SPs have two aspects:

  • ● Spending to SP addresses: the actual output script placed in a transaction depends on both the silent payment address and the inputs in the transaction. Any change to the inputs in a PSBT can potentially make an SP output unspendable by standard wallet software, so extra PSBT validation is required. Some input types can’t be used with SPs, which also needs validation.

    For the input types that can be used, the SP-aware spending logic needs the private key for those inputs, which may not be available to a software wallet when the underlying key is stored in a hardware signing device. Baker describes a scheme that may allow a spender to create an SP output script without the private key, but it has the potential to leak a private key, so it may not see implementation in hardware signing devices.

  • ● Spending previously received SP outputs: PSBTs will need to include the shared secret that is used as a tweak of the spending key. This can be just an additional PSBT field.

  Discussion was ongoing at the time of writing.

• ● Proposed miniscript BIP: Ava Chow posted to the Bitcoin-Dev mailing list a draft BIP for miniscript, a language that can be converted to Bitcoin Script but which allows composition, templating, and definitive analysis. The draft BIP is derived from miniscript’s long-standing website and should correspond with existing implementations of miniscript both for P2WSH witness script and P2TR tapscript.

• ● Channel value pegging: Tony Klausing posted to Delving Bitcoin a proposal, with working code, for stable channels. Imagine Alice wants to keep an amount of bitcoin that equals $1,000 USD. Bob is willing to guarantee that, either because he expects BTC to increase in value or because Alice is paying him a premium (or both). They open an LN channel together and, every minute, they perform the following actions:

  • They both check the same BTC/USD price sources.

  • If the value of BTC goes up, Alice reduces her bitcoin balance until it’s equal in value to $1,000 USD, transferring the excess to Bob.

  • If the value of BTC goes down, Bob sends enough BTC to Alice until her bitcoin balance is equal in value to $1,000 USD again.

  The goal is for the rebalancing to occur frequently enough that each price change is below the cost to the disadvantaged party of closing the channel, encouraging them to simply pay and continue the relationship.

  Klausing suggests that some traders could find this minimally trusted relationship preferable to custodial futures markets. He also suggests that it could be used as the basis for a bank that issues dollar-denominated ecash. The scheme would work for any asset for which a market price could be determined.

Changes to services and client software

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

• ● Silent payment resources: Several silent payment resources have been announced including a silentpayments.xyz informational website, two TypeScript libraries, a Go-based backend, a web wallet, and more. Caution is advised as most of the software is new, beta, or a work in progress.

• ● Cake Wallet adds silent payments: Cake Wallet recently announced their latest beta release supports silent payments.

• ● Coordinator-less coinjoin PoC: Emessbee is a proof-of-concept project to create coinjoin transactions without a central coordinator.

• ● OCEAN adds BOLT12 support: The OCEAN mining pool uses a signed message to associate a Bitcoin address to a BOLT12 offer as part of their Lightning payout setup.

• ● Coinbase adds Lightning support: Using Lightning infrastructure from Lightspark, Coinbase added Lightning deposit and withdrawal support.

• ● Bitcoin escrow tooling announced: The BitEscrow team announced a set of developer tools for implementing non-custodial Bitcoin escrow.

• ● Block’s call for mining community feedback: In an update to their 3nm chip progress, Block is seeking mining community feedback about mining hardware software features, maintenance, and other questions.

• ● Sentrum wallet tracker released: Sentrum is a watch-only wallet that supports a variety of notification channels.

• ● Stack Wallet adds FROST support: Stack Wallet v2.0.0 adds FROST threshold multisig support using the Modular FROST Rust library.

• ● Transaction broadcast tool announced: Pushtx is a simple Rust program that broadcasts transactions directly to the Bitcoin P2P network.

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.

• ● Bitcoin Inquisition 27.0 is the latest major release of this fork of Bitcoin Core designed for testing soft forks and other major protocol changes on signet. New in this release is signet enforcement of OP_CAT as specified in BIN24-1 and BIP347. Also included is “a new evalscript subcommand for bitcoin-util that can be used to test script opcode behavior”. Support has been dropped for annexdatacarrier and pseudo ephemeral anchors (see Newsletters #244 and #248).

• ● LND v0.18.0-beta.rc2 is a release candidate for the next major version of this popular LN 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.

• ● Bitcoin Core #27101 introduces support for JSON-RPC 2.0 requests and server responses. Notable changes are that the server always returns HTTP 200 “OK” unless there is an HTTP error or malformed request, it returns either error or result fields but never both, and single and batch requests result in the same error handling behavior. If version 2.0 isn’t specified in the request body, the legacy JSON-RPC 1.1 protocol is used.

• ● Bitcoin Core #30000 allows multiple transactions with the same txid to coexist in TxOrphanage by indexing them by wtxid instead of txid. The orphanage is a limited-size staging area that Bitcoin Core uses to store transactions which reference the txids of parent transactions that Bitcoin Core can’t currently access. If a parent transaction with the txid is received, the child can then be processed. Opportunistic 1-parent-1-child (1p1c) package acceptance sends a child transaction first, expecting it to be stored in the orphanage, and then sends the parent—allowing their aggregate feerate to be considered.

  However, when opportunistic 1p1c was merged (see Newsletter #301), it was known that an attacker could prevent an honest user from using the feature by preemptively submitting a version of a child transaction with invalid witness data. That malformed child transaction would have the same txid as an honest child but would fail validation when its parent was received, preventing the child from contributing to the CPFP package feerate necessary for package acceptance to work.

  Because transactions in the orphanage were indexed by txid before this PR, the first version of a transaction with a particular txid would be the one stored in the orphanage, so an attacker who could submit transactions faster and more frequently than an honest user could block the honest user indefinitely. After this PR, multiple transactions with the same txid can be accepted, each one with different witness data (and, thus, a different wtxid). When a parent transaction is received, the node will have enough information to drop any malformed child transactions and then perform the expected 1p1c package acceptance on a valid child. This PR was previously discussed in the PR Review Club summary in Newsletter #301.

• ● Bitcoin Core #28233 builds on #17487 to remove the periodic flush of the warm coins (UTXO) cache every 24 hours. Before #17487, frequent flushing to disk reduced the risk that a node or hardware crash would require a lengthy reindex procedure. After #17487, new UTXOs can be written to disk without emptying the memory cache—although the cache still needs to be emptied when it nears the maximum allocated memory space. A warm cache almost doubles the block validation speed on a node with the default cache settings, with even more improved performance available on nodes that allocate additional memory to the cache.

• ● Core Lightning #7304 adds a reply flow to offers-style invoice_requests when it can’t find a path to the reply_path node. CLN’s connectd will open a transient TCP/IP connection to the requesting node to deliver an onion message containing an invoice. This PR improves Core Lightning’s interoperability with LDK and also allows using onion messages even while only a few nodes support them (see Newsletter #283).

• ● Core Lightning #7063 updates the feerate security margin multiplier to dynamically adjust for likely fee increases. The multiplier tries to ensure that channel transactions pay enough feerate that they will be confirmed, either directly (for transactions that can’t be fee bumped) or through fee bumping. The multiplier now starts at 2x current feerate estimates for low rates (1 sat/vbyte) and gradually decreases to 1.1x as feerates approach the daily high maxfeerate.

• ● Rust Bitcoin #2740 adds a from_next_work_required method to the pow (proof of work) API that takes a CompactTarget (representing the previous difficulty target), a timespan (the time difference between the current and previous blocks), and a Params network parameters object. It returns a new CompactTarget representing the next difficulty target. The algorithm implemented in this function is based on the Bitcoin Core implementation found in the pow.cpp file.