{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-04\n📝 Original message:On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e wrote:\n\u003e On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote:\n\u003e\u003e I still repeat my concern that any private key secret sharing scheme\n\u003e\u003e really ought to be compatible with threshold ECDSA, otherwise we're\n\u003e\u003e just going to have another redundant specification.\n\u003e\n\u003e 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.\n\nWell, if you're not doing anything homorphic with the result the\ncomputation should probably be over a small field (for computational\nefficiency and implementation simplicity reasons) and the data split\nup, this also makes it easier to deal with many different data sizes,\nsince the various sizes will more efficiently divide into the small\nfield.   The field only needs to be large enough to handle the number\nof distinct shares you wish to issue, so even an 8 bit field would\nprobably be adequate (and yields some very simple table based\nimplementations).\n\nIf that route is taken, rather than encoding BIP32 master keys, it\nwould probably be prudent to encode the encryption optional version\nhttps://bitcointalk.org/index.php?topic=258678.0 ... and if we're\ntalking about a new armored private key format then perhaps we should\nbe talking about Mark Friedenbach's error correcting capable scheme:\nhttps://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki\n(though it would be nicer if we could find a decoding scheme that\nsupported list decoding without increasing the complexity of a basic\nimplementation, since an advanced recovery tool could make good use of\na list decode)\n\nI'd think that changing to a small field with a simple implementation,\nand encoding the form with encryption, etc. probably makes it distinct\nenough from an implementation of ECDSA thresholding that redundancy\nisn't a problem."}