path: root/dd/a32ee7f2214d821736d74bc90bb34fdd22d4af

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <marek@palatinus.cz>) id 1VbqA8-0003wG-10
	for bitcoin-development@lists.sourceforge.net;
	Thu, 31 Oct 2013 11:11:40 +0000
X-ACL-Warn: 
Received: from mail-vc0-f173.google.com ([209.85.220.173])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VbqA6-00053K-3g
	for bitcoin-development@lists.sourceforge.net;
	Thu, 31 Oct 2013 11:11:39 +0000
Received: by mail-vc0-f173.google.com with SMTP id lh4so1825401vcb.18
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 31 Oct 2013 04:11:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc:content-type;
	bh=zDT0Qq3nOUmM0zVOq++E9yxs0AL6vi0wgjIA6+XmELg=;
	b=gKRXNYHOxynIOTlib1pCZGDeSS9HmHpFMzAVyrjotc5VSuH+qHcjojX83hI9ha60UI
	K9wrs/GaiC8dTM+IY9WyAITIXPQNt0cduiLheUdlMv/jx5U9Er6kubhHcaXrQRMTfr3X
	P0r5aMl7tLCO73PuFGhcIeUIj4O/glon2D5m0m92Z5NWkbg7i2Y9imxZv2hHL7MTql66
	7WglX421JE+cMBz6ZVCWhAW5k8uMirNKP8hqsocZxrPghSl/5nYi/0jpMl4s9nystCCA
	1aEYQuznybUV0idXyuH8lWjI6o86yq5WqZP5Aj/Yt+tibKXiFfbEWff3legt++4Y5f4h
	R1Og==
X-Gm-Message-State: ALoCoQnAFpkqdqPYbwuCQKpLc5FD7r7LM8NVC9DsQoMb9FI43WF29k/8UgykUEwPeSv9++zh4YPN
X-Received: by 10.52.69.200 with SMTP id g8mr76415vdu.36.1383217892565; Thu,
	31 Oct 2013 04:11:32 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.59.1.2 with HTTP; Thu, 31 Oct 2013 04:11:02 -0700 (PDT)
In-Reply-To: <52721F47.30206@gmx.de>
References: <trinity-ba3941a0-f758-4372-b431-c64e9b44328a-1382635758149@3capp-gmx-bs09>
	<CAJna-HjgpRhLdVGh+prx54VezHaH1vXGpPotW1Xkz2tiAiWrbg@mail.gmail.com>
	<526BDEC2.2090709@gmx.de>
	<CAJna-HgH1g8iiSvxXrJuga808SQJ6DKo4AYw4fxpwTRCsL+EyQ@mail.gmail.com>
	<CAPg+sBiuLJJV3pB-EF3O9sgB_Z3tuLhEg9k=A9mcxJvgy3UQSw@mail.gmail.com>
	<52721F47.30206@gmx.de>
From: slush <slush@centrum.cz>
Date: Thu, 31 Oct 2013 12:11:02 +0100
X-Google-Sender-Auth: pxLNzzIGNkuKvnR1pt37P-jL-ZE
Message-ID: <CAJna-HgD-Vgd_n8x=cD4dAoARMy0LoZJ29_y=tBoX4XYG03XqA@mail.gmail.com>
To: Thomas Voegtlin <thomasv1@gmx.de>
Content-Type: multipart/alternative; boundary=20cf307d045422470d04ea0783d6
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(slush[at]centrum.cz)
	0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
	See
	http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
	for more information. [URIs: gmx.de]
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1VbqA6-00053K-3g
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal to replace BIP0039
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 31 Oct 2013 11:11:40 -0000

--20cf307d045422470d04ea0783d6
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 31, 2013 at 10:13 AM, Thomas Voegtlin <thomasv1@gmx.de> wrote:

> Indeed, I want to include a version number in the seed phrase because
> there are
> multiple ways to define the tree structure used with BIP32. It is
> certainly too early
> to make final decisions on that, or to achieve a common standard.
>

Well, as we're the first pioneers of bip32, let's start using it in some
sane way and I'm sure the others will join. Just because they don't want to
incompatible software.

Actually I quite like that you're not wasting bip32 space by using some
dynamic allocatons in higher address space, so I'm happy to follow your
rules and I think we can agree on generic discover algorithm which maybe
won't be optimal, but will find all used addresses and won't need any
additional information directly in mnemonic.

As I wrote in previous post, in worst case I can imagine dropdown list on
import dialog, which will ask user which software has been handling the
seed before, to speedup the scan. But for now I don't see this necessary at
all.

Also, I can imagine that bip32 itself might be superseeded in the future.
>
>
Although I can imagine that as well, I hope that it won't be the case. We
need to unite and integrate instead of making incompatible applications.

One disadvantage of bip32 is that in fact it is too much flexible, so we
even falled into the necessity of defining version of discovery algorithm.
Lets set up best practices how to use it and other will follow instead of
creating zillion cross-incompatible algorithms which won't understand each
to other.


> The other question we might be solving is strenghtening (your proposal).
> I consider
> that this is not a strong requirement for Electrum, because it does not
> let the user
> choose their seed phrase. However, if a few bits of the seed phrase are
>

Hardening and password protection are two unrelated requirements. Again,
there are some scenarios in which use can leak part of the mnemonic to
attacker, so hardening prevent to bruteforce the rest information by
attacker, even if the mnemonic isn't passphrase protected.

I'm especially refering to our algorithm of mnemonic import to Trezor
during disaster recovery (when Trezor is destroyed and user wants to import
the seed to another one), so that leak isn't just a theoretical concept,
but real-word scenario.


> allocated

for metadata, then I guess strenghtening can be part of it. That's
> another good
> reason to have a version number encapsulated in the seed.
>

Actually creating optional features of such algorithm only make things
complicated (and less cross-compatible). Every software still needs to
implement such hardening even if it is optional feature, to be compatible
with other clients. Then I don't see any reason why to have it optional.

Don't forget that the proposal uses only 4 bits of version, which isn't too
much combination for all these optional features ;-).

I too wonder why the transformation needs to be bidirectional in bip39.
>
>
Well, I wrote longer answer in previous  email. tl;dr; there's quite easy
way how to make the algorithm bi-directional, so I don't see a necessity to
drop potentially useful feature for no good reason.

I was thinking about your proposal and I realized that both our solutions
solves a bit different problem. Lets summarize features (and forget to
wordlist fights for moment):

bip39:
+ bi-directional
+ passphrase protected
+ shorter mnemonic or shorter wordlist
- predefined wordlist

ThomasV proposal:
+ any software can has its own preferred worlist
? passphrase protected
- one-direction only
- longer mnemonic or longer wordlist

Back to wordlist fights
a) actually I think that the wordlist choice is far less important than it
may look at first glance. Thomas thinks that bip39 wordlist is disaster, me
and many other thinks it is ok, but mainly that it is very subjective.

b) I see the beauty of "custom wordlists" in Thomas proposal, still if it
means the algorithm is uni-direction only, it is very strong disadvantage
to our usecase.

c) I advocated our wordlist mainly because we put a lot of effort into it
and after many weeks of tuning it is already done; not because I think that
one method of picking the words is superior to other. I mean - if Thomas
can offer any other plain-english wordlist which he'll be happy with, I'll
vote for dropping our own wordlist and to use Thomas's version for the deal
that he'll accept our need for bi-directionality and he agrees on the rest
of bip39 ;-).

Marek

--20cf307d045422470d04ea0783d6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Oct 31, 2013 at 10:13 AM, Thomas Voegtlin <span di=
r=3D"ltr">&lt;<a href=3D"mailto:thomasv1@gmx.de" target=3D"_blank">thomasv1=
@gmx.de</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Indeed, I want to include a version number i=
n the seed phrase because<br>
there are<br>
multiple ways to define the tree structure used with BIP32. It is<br>
certainly too early<br>
to make final decisions on that, or to achieve a common standard.<br></bloc=
kquote><div><br></div><div style>Well, as we&#39;re the first pioneers of b=
ip32, let&#39;s start using it in some sane way and I&#39;m sure the others=
 will join. Just because they don&#39;t want to incompatible software.</div=
>

<div style><br></div><div style>Actually I quite like that you&#39;re not w=
asting bip32 space by using some dynamic allocatons in higher address space=
, so I&#39;m happy to follow your rules and I think we can agree on generic=
 discover algorithm which maybe won&#39;t be optimal, but will find all use=
d addresses and won&#39;t need any additional information directly in mnemo=
nic.</div>

<div style><br></div><div style>As I wrote in previous post, in worst case =
I can imagine dropdown list on import dialog, which will ask user which sof=
tware has been handling the seed before, to speedup the scan. But for now I=
 don&#39;t see this necessary at all.</div>

<div style><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, I can imagine that bip32 itself might be superseeded in the future.<b=
r>
<br></blockquote><div><br></div><div style>Although I can imagine that as w=
ell, I hope that it won&#39;t be the case. We need to unite and integrate i=
nstead of making incompatible applications.</div><div style><br></div>

<div style>One disadvantage of bip32 is that in fact it is too much flexibl=
e, so we even falled into the necessity of defining version of discovery al=
gorithm. Lets set up best practices how to use it and other will follow ins=
tead of creating zillion cross-incompatible algorithms which won&#39;t unde=
rstand each to other.</div>

<div style>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The other question we might be solving is strenghtening (your proposal).<br=
>
I consider<br>
that this is not a strong requirement for Electrum, because it does not<br>
let the user<br>
choose their seed phrase. However, if a few bits of the seed phrase are<br>=
</blockquote><div><br></div><div style>Hardening and password protection ar=
e two unrelated requirements. Again, there are some scenarios in which use =
can leak part of the mnemonic to attacker, so hardening prevent to brutefor=
ce the rest information by attacker, even if the mnemonic isn&#39;t passphr=
ase protected.</div>

<div style><br></div><div style>I&#39;m especially refering to our algorith=
m of mnemonic import to Trezor during disaster recovery (when Trezor is des=
troyed and user wants to import the seed to another one), so that leak isn&=
#39;t just a theoretical concept, but real-word scenario.</div>

<div style>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">
allocated=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
for metadata, then I guess strenghtening can be part of it. That&#39;s<br>
another good<br>
reason to have a version number encapsulated in the seed.<br></blockquote><=
div><br></div><div style>Actually creating optional features of such algori=
thm only make things complicated (and less cross-compatible). Every softwar=
e still needs to implement such hardening even if it is optional feature, t=
o be compatible with other clients. Then I don&#39;t see any reason why to =
have it optional.</div>

<div style>=A0</div><div style>Don&#39;t forget that the proposal uses only=
 4 bits of version, which isn&#39;t too much combination for all these opti=
onal features ;-).</div><div style><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>


I too wonder why the transformation needs to be bidirectional in bip39.<br>
<br></blockquote><div><br></div><div style>Well, I wrote longer answer in p=
revious =A0email. tl;dr; there&#39;s quite easy way how to make the algorit=
hm bi-directional, so I don&#39;t see a necessity to drop potentially usefu=
l feature for no good reason.</div>

<div style><br></div><div style>I was thinking about your proposal and I re=
alized that both our solutions solves a bit different problem. Lets summari=
ze features (and forget to wordlist fights for moment):</div><div style>

<br></div><div style>bip39:</div><div style>+ bi-directional</div><div styl=
e>+ passphrase protected</div><div style>+ shorter mnemonic or shorter word=
list</div><div style>- predefined wordlist</div><div style><br></div><div s=
tyle>

ThomasV proposal:</div><div style>+ any software can has its own preferred =
worlist</div><div style>? passphrase protected</div><div style>- one-direct=
ion only</div><div style>- longer mnemonic or longer wordlist</div><div sty=
le>

<br></div><div style>Back to wordlist fights</div><div style>a) actually I =
think that the wordlist choice is far less important than it may look at fi=
rst glance. Thomas thinks that bip39 wordlist is disaster, me and many othe=
r thinks it is ok, but mainly that it is very subjective.</div>

<div style><br></div><div style>b) I see the beauty of &quot;custom wordlis=
ts&quot; in Thomas proposal, still if it means the algorithm is uni-directi=
on only, it is very strong disadvantage to our usecase.</div><div style>

<br></div><div style>c) I advocated our wordlist mainly because we put a lo=
t of effort into it and after many weeks of tuning it is already done; not =
because I think that one method of picking the words is superior to other. =
I mean - if Thomas can offer any other plain-english wordlist which he&#39;=
ll be happy with, I&#39;ll vote for dropping our own wordlist and to use Th=
omas&#39;s version for the deal that he&#39;ll accept our need for bi-direc=
tionality and he agrees on the rest of bip39 ;-).</div>

<div style><br></div><div style>Marek</div><div style><br></div></div></div=
></div>

--20cf307d045422470d04ea0783d6--