Is there a reason you prefer doing the M-1 offset as opposed to limiting
the range to 255 instead? Seems like something that will certainly confuse
some developers in exchange for adding one more value at the high end of a
range. I don't gather there's much difference between 255 and 256 here is
there? Also requires the small bit of explanation to hang around as a rider
in all future documentation, and the name of the field may not be
self-documenting anymore.
By way of predicting how I'm wrong, perhaps it is better to have a field
where all possible values are legitimate (by not biasing you would have to
check it's not zero), or perhaps it's important that powers of 2 be
represented here? Perhaps there's some use case at 256 that 255 just won't
do for?
I'm mostly just curious, as I find problems and funnies crop up when people
get clever with optimization of things like message bit-packing etc.. If
it's not necessary then maybe better to keep to what's intuitive (i.e. the
girls name is clear and self-documenting)
Anyway enough of my bike shedding!
On Apr 22, 2014 5:38 AM, Matt Whitlock b...@mattwhitlock.name wrote:
On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock b...@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-.mediawiki
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
