[bitcoin-dev] METABIP: ONE SEED STANDARD

[bitcoin-dev] METABIP: ONE SEED STANDARD

[GOLEM XIV]

[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]

From a user perspective it is desirable that, independent from software/hardware used, a seed would be the only information necessary to recover a wallet. Unfortunately, many users think that is currently the case with BIP39, while at the same time it is marked as "Unanimously discourage for implementation" in the bitcoin wiki. The situation is confusing, and a arguably a threat to users funds.

This METABIP is *not* proposing or advocating a specific format. It only claims the importance and urgency of a clear definition, remaining indifferent about the possible outcome even if it should be 'interoperability is not desired'. Its purpose is to be as synthetic and clear as possible about the characteristics of each existing format. Advantages/disadvantages categorization was explicitly avoided.

BIP39 (https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki):
- "Unanimously discouraged for implementation"
- widely implemented/supported
- weak KDF
- no version number
- no birth date
- requires a fixed word list
- extendable with pass phrases
- simple implementation

Electrum seeds (http://docs.electrum.org/en/latest/seedphrase.html):
- only supported by Electrum
- includes version number
- no birth date
- does not require a fixed word list
- extendable with pass phrases
- simple implementation

AEZeeds (https://github.com/lightningnetwork/lnd/tree/master/aezeed):
- only supported by LND
- includes version number
- includes birth date
- requires fixed word list
- pass phrase not only extends, but encrypts seed
- pass phrase can be modified
- complex implementation¹

Cypherseed(https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991):
Includes all aspects of AEZeeds, with the differences:
- still in draft stage
- does not use words at all, but 5char blocks
- uses MAC tags for plausible deniability

¹) AEZ is an authenticated-encryption (AE) scheme optimized for ease of correct use (“AE made EZ”). - "Easy to use, not to implement. The easiness claim for AEZ is with respect to ease and versatility of use, not implementation. Writing software for AEZ is not easy, while doing a hardware design for AEZ is far worse. From the hardware designer’s perspective, AEZ’s name might seem ironic, the name better suggesting anti-easy, the antithesis of easy, or anything-but easy!" - quoted from the original AEZ paper (http://web.cs.ucdavis.edu/~rogaway/aez/aez.pdf)

Hopefully, a tiny step towards consensus in this sensible theme.

G.
--
// there would be no flight without the dream of flying - Lem

[-- Attachment #2: Type: text/html, Size: 3696 bytes --]