|Category||Notational standards (1xx)|
|Author||Eric Tung firstname.lastname@example.org|
Standardizes a backwards-compatible and extensible family of formats for representing wallet secret keys, “seed phrases”, and similar.
Currently, there is no standard way of representing wallet secret keys in the Mel ecosystem. Old
melwalletd uses one way, new
melwallet-cli uses another way, etc.
Worse, there are at least three different “standard covenants” that check for signatures (the “old” covenant that checks the first signature, the “standard” covenant that checks the nth signature, and the future turing-complete covenant that checks all the signatures), and wallet secret keys have no way of indicating which one is meant.
In addition, we want to eventually support things beyond just a single ed25519 keypair — for example, Bitcoin-like multiaddress wallets — where the “master secret” will not be a simple ed25519 secret key.
We propose a flexible wallet secret encoding format consisting of two parts:
- A 8-bit key type, indicating what kind of wallet key is this.
0x01: ed25519 secret key, “standard” covenant
- An arbitrary-length bytestring payload, whose interpretation depends on the key type
0x01, that’d be an ed25519 secret key, which does contain the public part.
There are two encodings, a succinct encoding using base32, and a phrase encoding that uses a wordlist
This is simply the unpadded, uppercase Crockford base32 encoding of the bytestring
key_type || payload, prepended with “SK-”.
TODO: have some encoding that
- uses a standard wordlist like the EFF wordlist or the BIP39 wordlist
- encodes a whitened version where every bit is equally likely and important, and there’s error detection like a crc32 checksum. this probably would use some sort of hack with a stream cipher like ChaCha20.
When decoding, try all possible encodings:
- Try to decode as the succinct encoding
- Try to decode as the phrase encoding
- Try to decode as the legacy encoding, which is the one that melwalletd produces