On Friday, 4 April 2014, at 9:25 am, Gregory Maxwell wrote: > On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock <b...@mattwhitlock.name> wrote: > > On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote: > >> I still repeat my concern that any private key secret sharing scheme > >> really ought to be compatible with threshold ECDSA, otherwise we're > >> just going to have another redundant specification. > > > > I have that concern too, but then how can we support secrets of sizes other > > than 256 bits? A likely use case for this BIP (even more likely than using > > it to decompose Bitcoin private keys) is using it to decompose BIP32 master > > seeds, which can be 512 bits in size. We can't use secp256k1_n as the > > modulus there. > > Well, if you're not doing anything homorphic with the result the > computation should probably be over a small field (for computational > efficiency and implementation simplicity reasons) and the data split > up, this also makes it easier to deal with many different data sizes, > since the various sizes will more efficiently divide into the small > field. The field only needs to be large enough to handle the number > of distinct shares you wish to issue, so even an 8 bit field would > probably be adequate (and yields some very simple table based > implementations).
Are you proposing to switch from prime fields to a binary field? Because if you're going to "break up" a secret into little pieces, you can't assume that every piece of the secret will be strictly less than some 8-bit prime modulus. And if you're going to do a base conversion, then you have to do arbitrary-precision integer math anyway, so I don't see that the small field really saves you any code. > If that route is taken, rather than encoding BIP32 master keys, it > would probably be prudent to encode the encryption optional version > https://bitcointalk.org/index.php?topic=258678.0 ... and if we're > talking about a new armored private key format then perhaps we should > be talking about Mark Friedenbach's error correcting capable scheme: > https://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki > (though it would be nicer if we could find a decoding scheme that > supported list decoding without increasing the complexity of a basic > implementation, since an advanced recovery tool could make good use of > a list decode) Weren't you just clamoring for implementation *simplicity* in your previous paragraph? :) ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
