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
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
I see the first evidence of a problem in BIP32, where it suggests there is such a thing as a wallet structure. This was extended and formalised into a purpose as part of a derivation path in BIP43.
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.
I’ve said a lot about how wallet recovery using seed words does not work for real world wallets, like any that will be used into the future on Bitcoin SV. If you are not familiar with this, you can take a few minutes to read my article on the subject.
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
So we come back to BIP32 being the most tried and tested tool we have for hierarchical key generation. We could easily substitute it for any other technique, whether whitepaper 42 or otherwise. But we don’t have well proven usage of those other possibilities yet, so it is an easy choice to keep using BIP32.
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
I think the simple payments led to no examination of whether it made sense that all keys should be derived from a wallet’s master private key. Moving forward the master private key and it’s metadata also serves as a container for the linking in of non-derived resources.
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.
It goes without saying that BIP44 is irrelevant..
Thoughts welcome on the article.