From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WcZDo-0005q9-25 for bitcoin-development@lists.sourceforge.net; Tue, 22 Apr 2014 11:50:44 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.182 as permitted sender) client-ip=209.85.220.182; envelope-from=allport@gmail.com; helo=mail-vc0-f182.google.com; Received: from mail-vc0-f182.google.com ([209.85.220.182]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WcZDk-0007kJ-Jm for bitcoin-development@lists.sourceforge.net; Tue, 22 Apr 2014 11:50:43 +0000 Received: by mail-vc0-f182.google.com with SMTP id ib6so2474777vcb.27 for ; Tue, 22 Apr 2014 04:50:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.202.133 with SMTP id ki5mr34727731vec.19.1398167435049; Tue, 22 Apr 2014 04:50:35 -0700 (PDT) Received: by 10.52.145.145 with HTTP; Tue, 22 Apr 2014 04:50:34 -0700 (PDT) Received: by 10.52.145.145 with HTTP; Tue, 22 Apr 2014 04:50:34 -0700 (PDT) In-Reply-To: <9644584.QTKx69qfup@crushinator> References: <2336265.urqHVhRi8n@crushinator> <9644584.QTKx69qfup@crushinator> Date: Tue, 22 Apr 2014 07:50:34 -0400 Message-ID: From: Justin A To: Matt Whitlock Content-Type: multipart/alternative; boundary=047d7bea42604d831904f7a039a3 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (allport[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WcZDk-0007kJ-Jm Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 11:50:44 -0000 --047d7bea42604d831904f7a039a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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" wrote: > On Tuesday, 22 April 2014, at 10:39 am, Jan M=C3=B8ller wrote: > > On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock >wrote: > > > On Tuesday, 22 April 2014, at 10:27 am, Jan M=C3=B8ller wrote: > > > > > > - Please allow M=3D1. 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 =3D 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --047d7bea42604d831904f7a039a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 certa= inly confuse some developers in exchange for adding one more value at the h= igh 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 ha= ng 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 y= ou would have to check it's not zero), or perhaps it's important th= at powers of 2 be represented here? Perhaps there's some use case at 25= 6 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&= #39;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&quo= t; <bip@mattwhitlock.name&g= t; wrote:
On Tuesday, 22 April 2014, at 10:39 am, Jan M=C3=B8ller wrote:
> On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock <bip@mattwhitlock.name>wrote:
> > On Tuesday, 22 April 2014, at 10:27 am, Jan M=C3=B8ller wrote: > > > > > =C2=A0- Please allow M=3D1. From a usability point= of view it makes sense to allow
> > > > > the user to select 1 share if that is what he want= s.
> > > >
> > > > How does that make sense? Decomposing a key/seed into 1= share is
> > > > functionally equivalent to dispensing with the secret s= haring 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 c= an be 1 then
> > > the software/hardware doesn't have to support multiple f= ormats,
> > > import/export paths + UI =C2=A0(one for SIPA keys in one sha= re, one for HD seeds
> > > in one share, one for SIPA keys + HD seeds in multiple share= s).
> > >
> > > Less complexity & more freedom of choice.
> >
> > Alright. It's a fair argument. Do you agree with encoding M u= sing a bias
> > of -1 so that M up to and including 256 can be encoded in one byt= e?
>
> Necessary Shares =3D M+1, not a problem
>
> I would probably encode N-of-M in 1 byte as I don't see good use c= ases 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.n= et/sfu/ExoPlatform
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--047d7bea42604d831904f7a039a3--