BIP Proposal: New Serialization Format for Key Material
Extended private keys are defined in
BIP321 and are
used to recover funds in case of a loss, but recovering a wallet using just the
extended private keys is a tricky process and can sometimes fail to recover all
the funds as some metadata can be missing. The current implemenation also has a
weakness in which there is a limit to the incoming payment requests, handing
out more than
20 incoming payment requests could lead to destruction of funds.
To remedy this issue, an early draft of a new serialization/encoding format for extended public and private keys was proposed on the Bitcoin-dev channel.
Recovering a wallet by its extended private master key (xpriv; may or may not be at depth 0) is a complex task with risks of failing to recover all available funds.
I’m generally under the assumption that recovering funds based on the sole existence of an xpriv (or seed) without further metadata is a fragile concept.
Second, the missing birthday-metadata tend to lead to non-optimal blockchain scans (eventually increased p2p traffic). Recovering funds can take hours.
Additionally, the BIP44 gap limit seems to be a weak construct. The current gap limit in BIP44 is set to 20 2 which basically means, handing out more then 20 incoming payment requests (addresses) results in taking the risks that funds may be destroyed (or at least not detected) during a recovery.
This proposals could also make BIP 178 obsolete since it can be replace the WIF3 standard.
The new proposal is an error tolerant encoding format for key material that
includes minimal metadata, it’s a bech32 encoding that can include up to
bits for key material along with metadata of script type, version, key birthday
and a gap limit that can have up to
12 bits, new software is going to be needed
for these adjustments so if they hit the mainnet anytime soon, they’ll likely
be by a soft fork.
Support us and the authors of this article by donating to the following address:3GJfywoGxBzRFFaPG83EqzuqbPQeaTUZbM