This week’s newsletter summarizes a discussion about using SIGHASH_ANYPREVOUT to emulate aspects of drivechains. Also included are our regular sections describing recent changes to services, client software, and popular Bitcoin infrastructure software.

News

  • ● Creating drivechains with APO and a trusted setup: Jeremy Rubin posted to the Bitcoin-Dev mailing list a description for how a trusted setup procedure could be combined with the proposed SIGHASH_ANYPREVOUT opcode to implement behavior similar to that proposed by drivechains. Drivechains are a type of sidechain where miners are normally responsible for keeping the sidechain funds secure (in contrast to full nodes which are responsible for securing funds on Bitcoin’s mainchain). Miners attempting to steal drivechain funds must broadcast their malicious intentions days or weeks in advance, giving users a chance to change their full nodes to enforce the rules of the sidechain. Drivechains are primarily proposed for inclusion into Bitcoin as a soft fork (see BIPs 300 and 301), but a previous post to the mailing list (see Newsletter #190) described how some other flexible proposed additions to Bitcoin’s contracting language could also allow the implementation of drivechains.

    In this week’s post, Rubin described yet another way drivechains could be implemented using a proposed addition to Bitcoin’s contracting language, in this case using SIGHASH_ANYPREVOUT (APO) as proposed in BIP118. The described APO-based drivechains have several drawbacks compared to BIP300 but perhaps provides similar enough behavior that APO can be considered as enabling drivechains, which some individuals may consider a benefit and others may consider a problem.

Changes to services and client software

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

  • ● Mempool Project launches Lightning Network explorer: Mempool’s open source Lightning dashboard shows aggregate network statistics as well as individual node liquidity and connectivity data.

  • ● Federation software Fedimint adds Lightning: In a recent blog post, Blockstream outlines updates to the Fedimint federated Chaumian e-cash project, including Lightning Network support. The project also announced a public signet and faucet are available.

  • ● Bitpay wallet improves RBF support: Bitpay improves its existing support for sending RBF transactions by better handling bumping of transactions with multiple receivers.

  • ● Mutiny Lightning wallet announced: Mutiny (previously pLN), a privacy-focused Lightning wallet that uses separate nodes for each channel, was announced.

Notable code and documentation changes

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

  • ● Core Lightning #5581 adds a new event notification topic “block_added”. Subscribing plugins get notified each time a new block is received from bitcoind.

  • ● Eclair #2418 and #2408 add support for receiving payments sent with blinded routes. A spender creating a blinded payment isn’t provided with the identity of the node receiving the payment. This may improve privacy, especially when used with unannounced channels.

  • ● Eclair #2416 adds support for receiving payments requested using the offers protocol as defined in the proposed BOLT12. This uses the recently-added support for receiving blinded payments (see the previous list item for Eclair #2418).

  • ● LND #6335 adds a TrackPayments API that allows subscribing to a feed of all local payment attempts. As described in the PR description, this can be used to collect statistical information about payments to help better send and route payments in the future, such as for a node performing trampoline routing.

  • ● LDK #1706 adds support for using compact block filters as specified in BIP158 for downloading confirmed transactions. When used, if the filter indicates that a block may contain transactions affecting the wallet, the full block of up to 4 megabytes is downloaded. If it’s certain the block doesn’t contain any transactions affecting the wallet, no additional data is downloaded.