On 12 May 2014 15:09, Jan Møller <jan.mol...@gmail.com> wrote: > > I think having 3 encoding formats (long/short/compact) is over engineered, > and basically only makes implementing the standard a pain in the rear. From > a user experience point of view only the long format makes sense, and it is > only a few bytes longer than the short version. >
True. Since nobody has objected, the draft has been reworked and is much leaner now: https://github.com/cetuscetus/btctool/blob/bip/bip-xxxx.mediawiki . The reasons for not making M and checksum fields optional are added to the Rationale section. The main difference is that the shared secret can be in encoded form, e.g. SIPA or BIP38 instead of a plain private key. This makes SSS a general purpose container for any kind of secret data. The benefits are: - no need to change the spec to carry another type of content; - testnet and altcoins do not need any treatment in this spec; - content-specific metadata, such as compressed/uncompressed, encrypted/non-encrypted, key inception time point etc., are encoded together with the secret, rather than provided for separately and individually in this spec. As we are now dealing with secrets of arbitrary length, GF(256) as the underlying field becomes much more advantageous than GF(large prime). An inconvenience of variable length is that we have no control of the Base58 prefix. This was solved by moving the magic prefix outside of the Base58 encoded content: SSS-abcdefgh. 'SSS-' acts as the application identifier both to humans and machines, and abcdefgh is the Base58 encoding of the share without any application/magic bytes. (This may seem mildly controversial, but is there a better way?) ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
