{"type":"rich","version":"1.0","author_name":"npub1aeetueshkcgcx4x7uze7qteaq85d9d4c8kzrwxqmxq2rjnl5drmssu7ctd","author_url":"https://nostr.ae/npub1aeetueshkcgcx4x7uze7qteaq85d9d4c8kzrwxqmxq2rjnl5drmssu7ctd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-03\n📝 Original message:Matt Whitlock wrote:\n\u003e Okay, you've convinced me. However, it looks like the consensus here is\n\u003e that my BIP is unneeded, so I'm not sure it would be worth the effort\n\u003e for me to improve it with your suggestions.\n\nI need your BIP.\n\nWe are going to implement SSS and we'd rather stick with something\npublicly discussed, even if it has not formally become a BIP, than\ninvent our own stuff.\n\nI'll go ahead and comment on the current proposal here.  BIP or no\nBIP, I propose to finalise this spec anyway for those who want to\nimplement SSS now or in future.\n\nI agree with the recently mentioned suggestion to make non-essential\nmetadata, namely key fingerprint and degree (M), optional.  Their\n4-byte and 1-byte fields can be added individually at an\nimplementation's discretion.  During decoding, the total length will\ndetermine which fields are included.\n\nFor example, as a compromise between usability and security, the\nmetadata can be supplied out-of-band, like in plain text accompanying\nthe Base-58 encoded share.\n\nEncoding for the testnet is not specified.\n\nSpeaking of encoding, is it not wasteful to allocate three different\napplication/version bytes just for the sake of always starting with\n'SS'?  It would be OK if it were accepted as a BIP, but merely as a\nde-facto standard it should aim at minimising future chances of\ncollision.\n\nI'd add a clause allowing the use of random coefficients instead of\ndeterministic, as long as the implementation guarantees to never make\nanother set of shares for the same private key or master seed.\n\nWhat about using the same P256 prime as for the elliptic curve?  Just\nfor consistency's sake.\n\nAlso, I'm somewhat inclined towards using the actual x instead of j in\nthe encoding.  I find it more direct and straightforward to encode the\npair (x, y).  And x=0 can denote a special case for future extensions.\n There is no technical reason behind this, it's just for (subjective)\nclarity and consistency."}