📅 Original date posted:2014-04-22
📝 Original message:On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
> On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock <bip at mattwhitlock.name>wrote:
> > On Tuesday, 22 April 2014, at 10:27 am, Jan Møller wrote:
> > > > > - Please allow M=1. From a usability point of view it makes sense to allow
> > > > > the user to select 1 share if that is what he wants.
> > > >
> > > > How does that make sense? Decomposing a key/seed into 1 share is
> > > > functionally equivalent to dispensing with the secret sharing scheme
> > > > entirely.
> > > >
> > > I agree that it may look silly to have just one-of-one share from a
> > > technical point of view, but from an end-user point of view there could be
> > > reasons for just having one piece of paper to manage. If M can be 1 then
> > > the software/hardware doesn't have to support multiple formats,
> > > import/export paths + UI (one for SIPA keys in one share, one for HD seeds
> > > in one share, one for SIPA keys + HD seeds in multiple shares).
> > >
> > > Less complexity & more freedom of choice.
> >
> > Alright. It's a fair argument. Do you agree with encoding M using a bias
> > of -1 so that M up to and including 256 can be encoded in one byte?
>
> Necessary Shares = M+1, not a problem
>
> I would probably encode N-of-M in 1 byte as I don't see good use cases with
> more than 17 shares. Anyway, I am fine with it as it is.
Encoding bias of M changed to -1, and test vectors updated:
https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 15:17:12
in reply to nevent1q…vz62
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:17:12Event JSON
{
"id": "54fe9f24e94df6fa6b6d177437a42a3bd1f8cfce27b61251d86454e2e752d427",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686151032,
"kind": 1,
"tags": [
[
"e",
"ec3db7ea61043d2181c683590cc6472afc1e727a155c1437be680d2ee4f9939c",
"",
"root"
],
[
"e",
"87847e2b25d13ed58bdd0bb92a97e1b500764cdba2eb17e38687b16e5946cfd3",
"",
"reply"
],
[
"p",
"832a1862818484be65dd3985830db0dfab117e3f64b3ebf63a3062de9f57d848"
]
],
"content": "📅 Original date posted:2014-04-22\n📝 Original message:On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:\n\u003e On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003ewrote:\n\u003e \u003e On Tuesday, 22 April 2014, at 10:27 am, Jan Møller wrote:\n\u003e \u003e \u003e \u003e \u003e - Please allow M=1. From a usability point of view it makes sense to allow\n\u003e \u003e \u003e \u003e \u003e the user to select 1 share if that is what he wants.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e How does that make sense? Decomposing a key/seed into 1 share is\n\u003e \u003e \u003e \u003e functionally equivalent to dispensing with the secret sharing scheme\n\u003e \u003e \u003e \u003e entirely.\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e I agree that it may look silly to have just one-of-one share from a\n\u003e \u003e \u003e technical point of view, but from an end-user point of view there could be\n\u003e \u003e \u003e reasons for just having one piece of paper to manage. If M can be 1 then\n\u003e \u003e \u003e the software/hardware doesn't have to support multiple formats,\n\u003e \u003e \u003e import/export paths + UI (one for SIPA keys in one share, one for HD seeds\n\u003e \u003e \u003e in one share, one for SIPA keys + HD seeds in multiple shares).\n\u003e \u003e \u003e\n\u003e \u003e \u003e Less complexity \u0026 more freedom of choice.\n\u003e \u003e\n\u003e \u003e Alright. It's a fair argument. Do you agree with encoding M using a bias\n\u003e \u003e of -1 so that M up to and including 256 can be encoded in one byte?\n\u003e \n\u003e Necessary Shares = M+1, not a problem\n\u003e \n\u003e I would probably encode N-of-M in 1 byte as I don't see good use cases with\n\u003e more than 17 shares. Anyway, I am fine with it as it is.\n\nEncoding bias of M changed to -1, and test vectors updated:\nhttps://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki",
"sig": "2cee47b37b075262d7f9be93ca04b98bd8d02d4cd671640bcc4a70522ae15d7a3d04867c9d87d7e23dd9b1b225c79441e9a96d0b26248cbb5397b9becaffbf45"
}