📅 Original date posted:2014-04-22
📝 Original message: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?
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 15:17:11
in reply to nevent1q…k5j6
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetPublished at
2023-06-07 15:17:11Event JSON
{
"id": "a4763aece453cf1ef80e36fcc31c942abf4893bb97d55f8eaa9994751dd01990",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686151031,
"kind": 1,
"tags": [
[
"e",
"ec3db7ea61043d2181c683590cc6472afc1e727a155c1437be680d2ee4f9939c",
"",
"root"
],
[
"e",
"0064f4e027f976960c08c85d70570adf266a5bb16ca321b13ece65fe6fbf7cac",
"",
"reply"
],
[
"p",
"832a1862818484be65dd3985830db0dfab117e3f64b3ebf63a3062de9f57d848"
]
],
"content": "📅 Original date posted:2014-04-22\n📝 Original message:On Tuesday, 22 April 2014, at 10:27 am, Jan Møller wrote:\n\u003e \u003e \u003e - Please allow M=1. From a usability point of view it makes sense to\n\u003e \u003e allow\n\u003e \u003e \u003e the user to select 1 share if that is what he wants.\n\u003e \u003e\n\u003e \u003e How does that make sense? Decomposing a key/seed into 1 share is\n\u003e \u003e functionally equivalent to dispensing with the secret sharing scheme\n\u003e \u003e entirely.\n\u003e \u003e\n\u003e \u003e\n\u003e I agree that it may look silly to have just one-of-one share from a\n\u003e technical point of view, but from an end-user point of view there could be\n\u003e reasons for just having one piece of paper to manage. If M can be 1 then\n\u003e the software/hardware doesn't have to support multiple formats,\n\u003e import/export paths + UI (one for SIPA keys in one share, one for HD seeds\n\u003e in one share, one for SIPA keys + HD seeds in multiple shares).\n\u003e \n\u003e Less complexity \u0026 more freedom of choice.\n\nAlright. 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?",
"sig": "a661b6843be103eb0760c1bb5d145f2351d66fcfe0df40fa6201efadcd72ddc257074ed08d7838cd1b51e2b441ffd223440d03c31f0aeb2b60df3babfbe20ad8"
}