đź“… Original date posted:2014-04-22
đź“ť Original message: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.
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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/9a2dfdff/attachment.html>;
Jan Møller [ARCHIVE] /
npub1sv…jg7a4
2023-06-07 15:17:11
in reply to nevent1q…xvrc
Author Public Key
npub1sv4psc5psjztuewa8xzcxrdsm743zl3lvje7ha36xp3da86hmpyqdjg7a4Published at
2023-06-07 15:17:11Event JSON
{
"id": "25bec01101eb6b30a1db6159c62154f7fdbb7914d043f510783ee6a214a8b015",
"pubkey": "832a1862818484be65dd3985830db0dfab117e3f64b3ebf63a3062de9f57d848",
"created_at": 1686151031,
"kind": 1,
"tags": [
[
"e",
"ec3db7ea61043d2181c683590cc6472afc1e727a155c1437be680d2ee4f9939c",
"",
"root"
],
[
"e",
"a4763aece453cf1ef80e36fcc31c942abf4893bb97d55f8eaa9994751dd01990",
"",
"reply"
],
[
"p",
"f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91"
]
],
"content": "📅 Original date posted:2014-04-22\n📝 Original message:Necessary Shares = M+1, not a problem\n\nI would probably encode N-of-M in 1 byte as I don't see good use cases with\nmore than 17 shares. Anyway, I am fine with it as it is.\n\n\nOn Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003ewrote:\n\n\u003e On Tuesday, 22 April 2014, at 10:27 am, Jan Møller wrote:\n\u003e \u003e \u003e \u003e - Please allow M=1. From a usability point of view it makes sense to\n\u003e \u003e \u003e allow\n\u003e \u003e \u003e \u003e the user to select 1 share if that is what he wants.\n\u003e \u003e \u003e\n\u003e \u003e \u003e How does that make sense? Decomposing a key/seed into 1 share is\n\u003e \u003e \u003e functionally equivalent to dispensing with the secret sharing scheme\n\u003e \u003e \u003e entirely.\n\u003e \u003e \u003e\n\u003e \u003e \u003e\n\u003e \u003e I agree that it may look silly to have just one-of-one share from a\n\u003e \u003e technical point of view, but from an end-user point of view there could\n\u003e be\n\u003e \u003e reasons for just having one piece of paper to manage. If M can be 1 then\n\u003e \u003e the software/hardware doesn't have to support multiple formats,\n\u003e \u003e import/export paths + UI (one for SIPA keys in one share, one for HD\n\u003e seeds\n\u003e \u003e in one share, one for SIPA keys + HD seeds in multiple shares).\n\u003e \u003e\n\u003e \u003e Less complexity \u0026 more freedom of choice.\n\u003e\n\u003e Alright. It's a fair argument. Do you agree with encoding M using a bias\n\u003e of -1 so that M up to and including 256 can be encoded in one byte?\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/9a2dfdff/attachment.html\u003e",
"sig": "7d349f2a3dfe81748b8ed53f34aad75c1839bd834eca7716235ab5ca5010102f4c5979bd67f516f6f6f8e86dd409941bad6fa90547f6535b68a6f72104d6e3fd"
}