This week’s newsletter summarizes continued discussion about rewarding pool miners with tradeable ecash shares and describes a new proposal for enabling offchain resolution of DLCs. Also included are our regular sections announcing new releases and release candidates and describing notable changes to popular Bitcoin infrastructure software.

News

• ● Continued discussion about rewarding pool miners with tradeable ecash shares: discussion continued since our previous summary of a Delving Bitcoin thread about paying pool miners with ecash for each share they submitted. Previously, Matt Corallo asked why a pool would implement the extra code and accounting to handle tradable ecash shares when they could simply pay miners using a normal ecash mint (or via LN). David Caseria replied that in some pay per last N shares (PPLNS) schemes, such as TIDES, a miner might need to wait for the pool to find several blocks, which might take days or weeks for a small pool. Instead of waiting, a miner with ecash shares could immediately sell them on an open market (without disclosing to the pool or any third party anything about their identity, not even any ephemeral identity they used when mining).

  Caseria also noted that existing mining pools find it financially challenging to support the full paid per share (FPPS) scheme where a miner is paid proportional to the entire block reward (subsidy plus transaction fees) when they create a share. He didn’t elaborate, but we understand the problem to be variance in fees forcing pools to keep large reserves. For example, if a pool miner controls 1% of hashrate and creates shares on a template with about 1,000 BTC in fees and 3 BTC in subsidy, they would be owed by their pool about 10 BTC. However, if the pool doesn’t mine that block and, when they do mine a block, fees are back down to a fraction of the block reward, the pool might only have 3 BTC total to split between all of its miners, forcing it to pay from its reserves. If that happens too many times, the pool’s reserves will be exhausted and it will go out of business. Pools address this in various ways, including using proxies for actual fees.

  Developer vnprc described the solution he’s been building that focuses on ecash shares received in the PPLNS payout scheme. He thinks this could be especially useful for launching new pools: right now, the first miner to join a pool suffers the same high variance as solo mining, so typically the only people who can start a pool are existing large miners or those willing to rent significant hashrate. However, with PPLNS ecash shares, vnprc thinks a pool could launch as a client of a larger pool, so even the first miner to join the new pool would receive lower variance than solo mining. The intermediate pool could then sell the ecash shares it earns to finance whatever payout scheme it chooses to pay its miners. Once the intermediate pool acquired a significant amount of hashrate, it would also have leverage for negotiating with larger pools about creating alternative block templates that suit its miners.

• ● Offchain DLCs: developer conduition posted to the DLC-dev mailing list about a contract protocol that allows an offchain spend of the funding transaction signed by both parties to create multiple DLCs. After the offchain DLC has settled (e.g., all required oracle signatures have been obtained), a new offchain spend can be signed by both parties to reallocate funds according to the contract resolution. A third alternative spend can then allocate the funds to new DLCs.

  Replies by Kulpreet Singh and Philipp Hoenisch linked to previous research and development of this basic idea, including approaches that allow the same pool of funds to be used for both offchain DLCs and LN (see Newsletters #174 and #260). A reply from conduition described his proposal’s major difference from previous proposals.

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.1 is a milestone release of this library for building LN-enabled wallets and applications. New features include “support for both sides of the LSPS channel open negotiation protocols, […] includes support for BIP353 Human Readable Names resolution, [and a reduction in] on-chain fee costs when resolving multiple HTLCs for a single channel force-closure.”

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, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

• ● Eclair #2936 introduces a 12-block delay before marking a channel as closed after its funding output has been spent to allow for the propagation of a splice update (see Newsletter #214 and an Eclair developer’s description of the motivation). Spent channels are temporarily tracked in a new spentChannels map, where they are either removed after 12 blocks or updated as spliced channels. When a splice occurs, the parent channel’s short channel identifier (SCID), capacity, and balance bounds are updated instead of creating a new channel.

• ● Rust Bitcoin #3792 adds ability to encode and decode BIP324’s v2 P2P transport messages (see Newsletter #306). This is achieved by adding a V2NetworkMessage struct, which wraps the original NetworkMessage enum and provides v2 encoding and decoding.

• ● BDK #1789 updates the default transaction version from 1 to 2 to improve wallet privacy. Prior to this, BDK wallets were more identifiable due to only 15% of the network using version 1. In addition, version 2 is required for a future implementation of BIP326’s nSequence-based anti fee sniping mechanism for taproot transactions.

• ● BIPs #1687 merges BIP375 to specify sending silent payments using PSBTs. If there are multiple independent signers, a DLEQ proof is required to allow all signers to prove to co-signers that their signature doesn’t misspend funds, without revealing their private key (see Newsletter #335 and Recap #327).

• ● BIPs #1396 updates BIP78’s payjoin specification to align with BIP174’s PSBT specification, resolving a previous conflict. In BIP78, a receiver previously deleted UTXO data after completing its inputs, even if the sender needed the data. With this update, UTXO data is now retained.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 15:30 UTC on January 21. The discussion is also recorded and will be available from our podcasts page.