Matt Whitlock [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-29 📝 Original message:On Saturday, 29 March ...
📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 12:59 pm, Alan Reiner wrote:
> I won't lie, there's a lot of work that goes into making an interface
> that makes this feature "usable." The user needs clear ways to identify
> which fragments are associated with which wallet, and which fragments
> are compatible with each other.
The same is true of the multiple private keys involved in a multi-signature addresses.
> They need a way to save some fragments
> to file, print them, or simply write them down.
I proposed a share encoding scheme for exactly this purpose.
> They need a way to
> re-enter fragment, reject duplicates, identify errors, etc. Without it,
> the math fails silently, and you end up restoring a different wallet.
I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.
> Also I put the secret in the highest-order coefficient of the
> polynomial,
Does it make any difference which coefficient holds the secret? It's convenient to put it in the lowest-order coefficient to simply the recovery code.
> and made sure that the other coefficients were
> deterministic. This meant that if print out an M-of-N wallet, I can
> later print out an M-of-(N+1) wallet and the first N fragments will be
> the same. I'm not sure how many users would trust this, but we felt it
> was important in case a user needs to export some fragments, even if
> they don't increase N.
My BIP likewise deterministically chooses the coefficients so that the shares of a secret are consistent across all runs of the algorithm having the same M. As I'm sure you're aware, N (the number of shares to output) plays no part in the calculation and merely controls how many times the outermost loop is executed. My BIP doesn't even mention this parameter.
📝 Original message:On Saturday, 29 March 2014, at 12:59 pm, Alan Reiner wrote:
> I won't lie, there's a lot of work that goes into making an interface
> that makes this feature "usable." The user needs clear ways to identify
> which fragments are associated with which wallet, and which fragments
> are compatible with each other.
The same is true of the multiple private keys involved in a multi-signature addresses.
> They need a way to save some fragments
> to file, print them, or simply write them down.
I proposed a share encoding scheme for exactly this purpose.
> They need a way to
> re-enter fragment, reject duplicates, identify errors, etc. Without it,
> the math fails silently, and you end up restoring a different wallet.
I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.
> Also I put the secret in the highest-order coefficient of the
> polynomial,
Does it make any difference which coefficient holds the secret? It's convenient to put it in the lowest-order coefficient to simply the recovery code.
> and made sure that the other coefficients were
> deterministic. This meant that if print out an M-of-N wallet, I can
> later print out an M-of-(N+1) wallet and the first N fragments will be
> the same. I'm not sure how many users would trust this, but we felt it
> was important in case a user needs to export some fragments, even if
> they don't increase N.
My BIP likewise deterministically chooses the coefficients so that the shares of a secret are consistent across all runs of the algorithm having the same M. As I'm sure you're aware, N (the number of shares to output) plays no part in the calculation and merely controls how many times the outermost loop is executed. My BIP doesn't even mention this parameter.