User talk:Vbuterin
K_of_N_redundant_offline_private_key_proposal
User:Vbuterin/K_of_N_redundant_offline_private_key_proposal
I just checked Recent Changes and was excited to see you putting this together! A few things:
- Does this bear any similarity to "Shamir's secret-sharing scheme"? (which I know little about other than having skimmed the Wikipedia article)
- Your proposal points out that the payload will have varying lengths, but the same time, stipulates a prefix of 0x86 for the benefit of the user. Off the top of your head, how much do the lengths vary? The reason I ask is that the prefix on the base58 string as seen by the user only stays constant when the number of bytes in the message is constant. If the variation isn't that much, then adding padding bytes might work. For example, the private key that starts with '5' suddenly starts with a 'K' or 'L' when an extra byte is added. If it isn't clear why, a simple analogy can be made for hexadecimal vs. decimal: all four-digit decimal numbers that start with 5 (i.e. decimal numbers between 5000 and 5999) will have a hex equivalent that starts with 1, but it's not true for non-4-digit numbers: 50000 and 59999 will have a hex equivalent that starts not with 1, but instead, C, D, or E.
- Somewhere in the message, there should be a 1-bit flag that tells whether to create the bitcoin address from the uncompressed vs. compressed public key.
- Somewhere in the message, there ought to be a small handful of bits taken from the resulting bitcoin address, so a user interface accepting parts one by one can reliably detect and complain: "The last part you entered does not belong to the part(s) you entered before".
- Somewhere in the message, there should be a count that tells the UI how many total parts are needed and how many exist. (e.g. the values of K and N)