<unnamed>

Public Key

npub1lednscrafeg0up3n3u8vyr5d6kntsgr6q2y3nfhn0r8dh8vnvmgs6960tk

Profile Code

nprofile1qqs0ukecvp75u587qcec7rkzp6xatf4cypaq9zge5meh3nkmnkfkd5gprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqyxhwumn8ghj7mn0wvhxcmmvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hs74clq6

Publishing to

relay.snort.social

nos.lol

relay.damus.io

Last Notes

2023-06-07 15:17:12 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message: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" <bip at 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 <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
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/ffcc6955/attachment.html>