This week’s newsletter summarizes a proposal for creating a unified multi-wallet backup that circumvents the inability to import BIP32 extended private keys into many wallets that support deterministic key derivation. Also included are our regular sections describing release candidates and changes to popular Bitcoin infrastructure software.
None this week.
● Proposal for using one BIP32 keychain to seed multiple child keychains: several weeks ago, Ethan Kosakovsky posted to the Bitcoin-Dev mailing list a proposal for using one BIP32 Hierarchical Deterministic (HD) keychain to create seeds for child HD keychains that can be used in different contexts. This may seem unnecessary given that BIP32 already provides extended private keys (xprvs) that can be shared between signing wallets. The problem is that many wallets don’t implement the ability to import xprvs—they only allow importing either an HD seed or some precursor data that is transformed into the seed (e.g. BIP39 or SLIP39 seed words).
Kosakovsky’s proposal is to create a super-keychain whose child keys are transformed into seeds, seed words, or other data that can be input into various wallets’ HD keychain recovery fields. That way a user with multiple wallets can backup all of them using just the super-keychain’s seed (plus the derivation paths and the library for transforming deterministic entropy into input data).
Reaction to the proposal was mixed (pro: 1, 2; con: 1, 2), but this week one hardware wallet manufacturer stated their intent to implement support for the protocol and requested additional review of the proposal.
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 Core 0.20.0rc1 the first release candidate for the next major version of Bitcoin Core is available for testing by experienced users. Please report any problems you discover so that they can be fixed before the final release.
Notable code and documentation changes
● LND #3967 adds support for sending multipath payments, complementing the already-existing receiving logic. Previously, LND would fail to pay invoices whose full amount couldn’t be carried by a single route. With multipath payments, LND can now split invoices into smaller HTLCs which can each take a different route, making better use of the liquidity in LN. Users can control the maximum number of partial payments using an RPC parameter or command line option.
● LND #4075 allows invoices to be created for payments greater than the previous limit of around 0.043 BTC. The network-wide HTLC limit of 0.043 BTC prevents payments greater than that amount over a single channel. With the implementation of sending multipath payments also merged in LND this week, invoices can be issued for an aggregate payment amount greater than 0.043 BTC, which the sender then splits into partial payments.