This week’s newsletter describes a proposal for a standardized wallet label export format and includes our regular sections with summaries of recent questions and answers from the Bitcoin StackExchange, a list of new software releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.


  • Wallet label export format: Craig Raw posted to the Bitcoin-Dev mailing list a proposed BIP to standardize the format wallets use to export labels for their addresses and transactions. A standardized export format could in theory allow two pieces of wallet software that used the same BIP32 account hierarchy to open each others’ backups and recover not just funds but all of the information the user manually entered about their transactions.

    Given previous challenges to making BIP32 wallets compatible with each other, a perhaps more achievable use would be making it easier to export transaction history from a wallet and use it in other programs, such as for accounting.

    Developers Clark Moody and Pavol Rusnak each replied with a reference to SLIP15, which describes the open export format developed for Trezor brand wallets. Craig Raw noted several significant differences between what his proposed format is attempting to achieve and what SLIP15 seems to provide. Several other design aspects were also discussed, with discussion appearing to be ongoing as this summary was being written.

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.

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.

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.

  • Bitcoin Core #23202 extends the psbtbumpfee RPC with the ability to create a PSBT that fee bumps a transaction even if some or all of the inputs to the transaction don’t belong to the wallet. The PSBT can then be shared with the wallets that can sign it.

  • Eclair #2275 adds support for fee bumping a dual funded LN setup transaction. The PR notes that, with this PR, “dual funding is fully supported by Eclair!” Though it also notes that dual funding is disabled by default and that tests for cross compatibility with Core Lightning will be added in the future.

  • Eclair #2387 adds support for signet.

  • LDK #1652 updates support for onion messages with the ability to send reply paths, and to decode them when received. The onion message protocol doesn’t require a node which relays an onion message to track any information about that message after relay, so it can’t automatically send a reply back along the path the original message took. That means a node which wants a reply to its onion message needs to provide hints to the receiver about what path to use for sending a reply.

  • HWI #627 adds support for P2TR keypath spends using the BitBox02 hardware signing device.

  • BDK #718 begins verifying both ECDSA and schnorr signatures immediately after the wallet creates them. This is a recommendation of BIP340 (see Newsletter #87), was discussed in Newsletter #83, and was previously implemented in Bitcoin Core (see Newsletter #175).

  • BDK #705 and #722 give software using the BDK library the ability to access additional server-side methods available from Electrum and Esplora services.