📅 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.
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 15:16:40
in reply to nevent1q…myq9
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetPublished at
2023-06-07 15:16:40Event JSON
{
"id": "67f957ba0c4ded5fcc74304aedb7a796b51c4ab023fc529d49d20c8f96907c06",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686151000,
"kind": 1,
"tags": [
[
"e",
"cd470d06d90a3107c21da4b48b344ebdd3b4ab813362bb85b0e7a02311012700",
"",
"root"
],
[
"e",
"249e3818f1d7863ca6b5705711f64e4375a31cfac1da5457c579e43c7db252ee",
"",
"reply"
],
[
"p",
"86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec"
]
],
"content": "📅 Original date posted:2014-03-29\n📝 Original message:On Saturday, 29 March 2014, at 12:59 pm, Alan Reiner wrote:\n\u003e I won't lie, there's a lot of work that goes into making an interface\n\u003e that makes this feature \"usable.\" The user needs clear ways to identify\n\u003e which fragments are associated with which wallet, and which fragments\n\u003e are compatible with each other.\n\nThe same is true of the multiple private keys involved in a multi-signature addresses.\n\n\u003e They need a way to save some fragments\n\u003e to file, print them, or simply write them down.\n\nI proposed a share encoding scheme for exactly this purpose.\n\n\u003e They need a way to\n\u003e re-enter fragment, reject duplicates, identify errors, etc. Without it,\n\u003e the math fails silently, and you end up restoring a different wallet.\n\nI 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.\n\n\u003e Also I put the secret in the highest-order coefficient of the\n\u003e polynomial,\n\nDoes 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.\n\n\u003e and made sure that the other coefficients were\n\u003e deterministic. This meant that if print out an M-of-N wallet, I can\n\u003e later print out an M-of-(N+1) wallet and the first N fragments will be\n\u003e the same. I'm not sure how many users would trust this, but we felt it\n\u003e was important in case a user needs to export some fragments, even if\n\u003e they don't increase N.\n\nMy 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.",
"sig": "cfe72f6bf55791eba24c4519d78eef93693802925b3d896317e3c2021f8aab807df4a665c757a0c96a76301dc4861af6d33556826d374a6ad8d916d1f486b87f"
}