Better off without BIP43?

Exploring the assumptions of BIP32 and BIP43

This article is not about wallet backups per-se, although it does touch on the subject where it is related. It is more an attempt at writing down my current position on BIP32 and derivation paths. I’ve touched on it before in at least one previous article, but this one is more specific.

In the past, many specifications were designed around the building block of BIP32 key enumeration. One example of this was finding the BIP45 multi-signature usage of a master private key, by enumerating the receiving and change addresses of the declared BIP43 purpose 45.

Let’s take a look at why this is possibly no longer relevant, and if you propose your own BIP43 purposes, you might very well find ElectrumSV putting other stuff there.

BIP32 derivation paths

To illustrate this, the template for a BIP45 wallet using it’s declared purpose value of 45, was given as follows:


My current position is that BIP32 is the only reliable and tested tool we have for hierarchical key generation and enumeration. But it should be employed like a tool, not used to reserve derivation paths for set purposes. That was an easy choice from simpler times in the past, where wallets were more or less limited to simple payments.

Wallet backups

As a wallet does more and more interesting things, any useful backup of it’s activity will have to include metadata to go with the knowledge of what transactions were made. It is no longer necessary to enumerate and exhaust any potential derivation path usage under the wallet’s master private key. The metadata can and should include the same information that this would discover, as well as the additional information that gives it context.

The ability to know where things are in the BIP32 derivation paths, then becomes more of an artificial, arbitrary and limiting constraint than anything useful. The only reserved places in the derivation paths, should be the location of the metadata records, and those alone would be enumerated — in any hypothetical on-chain wallet recovery process.

BIP32 as a tool

A wallet might in response to some user action, dynamically allocate a BIP32 path for whatever purpose. As long as it does not conflict with the reserved metadata derivation paths, it does not matter where it is. It can generate a relative sub-path fit for purpose, under the allocated position in the wallet’s key-space.

To illustrate this, the template for a BIP45 wallet would then be:


A wallet could then have any number of new-style (non-P2SH of course) BIP45 accounts within it, located under any arbitrarily allocated parent derivation path. Of course, only the wallet owner’s own co-signing in the multi-signature wallet would be within their key-space. The other cosigners would get an xpub for this sub-path, so they could watch and confirm the wallet owner’s participation in the multi-signature wallet. Their xpubs would be stored in the wallet metadata and associated with this account and it’s application.

The master private key as a container

If the multi-signature key-space I am the co-signer for and have the private key for was generated by an external party from their key-space or even randomly with a new private key of it’s own, then I should be able to integrate that into the wallets accounts and use it in much the same fashion as any other account.

The metadata now defines the wallet structure, and the derivation path space is merely a tool at it’s disposal.

Summing up

Thoughts welcome on the article.

ElectrumSV developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store