This week’s newsletter describes continued discussion about covenants in Bitcoin and includes our regular sections with summaries of changes to services and client software and notable changes to popular Bitcoin infrastructure software.

News

  • ● Simplified alternative to OP_TXHASH: in continuing discussion about covenant-enabling opcodes (see Newsletter #185), Rusty Russell proposed that the function provided by OP_TXHASH could be provided by the existing OP_SHA256 opcode plus a new OP_TX opcode which accepted the same input as OP_TXHASH. The new opcode would make serialized fields from a spending transaction available to a tapscript. Scripts could then test the fields directly (e.g. is the transaction version’s number greater than 1?) or hash the data and compare it to a signature with the previously-proposed OP_CHECKSIGFROMSTACK opcode.

Changes to services and client software

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

  • ● Blockchain.com Wallet adds taproot sends: v202201.2.0(18481) of the Blockchain.com Wallet for Android added support for sending to bech32m addresses. At the time of writing, the iOS version of the wallet does not yet support sending to bech32m addresses.

  • ● Sensei Lightning node implementation launches: Sensei, currently in beta, is built using the Bitcoin Dev Kit (BDK) and Lightning Dev Kit (LDK). The node currently requires Bitcoin Core and Electrum server with additional backend options planned.

  • ● BitMEX adds taproot sends: In a recent blog post, BitMEX announced support for bech32m withdrawals. The post also notes that 73% of BitMEX user deposits are received to P2WSH outputs and result in around 65% fee savings.

  • ● BitBox02 adds taproot sends: Both the v9.9.0 - Multi and v9.9.0 - Bitcoin-only releases add support for sending to bech32m addresses.

  • ● Fulcrum 1.6.0 adds performance improvements: Address indexing software Fulcrum adds performance improvements in the 1.6.0 release.

  • ● Kraken announces proof of reserves scheme: Kraken details their proof of reserves scheme involving a trusted auditor, also noting shortcomings and future improvements. Kraken creates digital signatures to prove onchain address ownership, produces a merkle tree of Kraken user account balances, asks an auditor to certify onchain balances are greater than account balances, and provides tooling for users to verify their balance was included in the tree.

Notable code and documentation changes

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

  • ● Eclair #2164 improves its handling of feature bits in various contexts. Notably, invoices that require a mandatory but non-invoice feature would no longer be rejected, since the lack of support for a non-invoice feature does not affect an invoice’s ability to be fulfilled.

  • ● BTCPay Server #3395 adds support for CPFP fee-bumping payments received to invoices and transactions sent by the wallet.

  • ● BIPs #1279 updates the BIP322 specification of the generic signmessage protocol with a few clarifications and test vectors.