1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
|
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 <ematiu@gmail.com>) id 1WTA1s-0002uz-CZ
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 13:07:32 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.180 as permitted sender)
client-ip=209.85.223.180; envelope-from=ematiu@gmail.com;
helo=mail-ie0-f180.google.com;
Received: from mail-ie0-f180.google.com ([209.85.223.180])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WTA1p-0003Nz-3s
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 13:07:30 +0000
Received: by mail-ie0-f180.google.com with SMTP id as1so3239848iec.25
for <bitcoin-development@lists.sourceforge.net>;
Thu, 27 Mar 2014 06:07:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.43.155.209 with SMTP id lj17mr913085icc.94.1395925643783;
Thu, 27 Mar 2014 06:07:23 -0700 (PDT)
Received: by 10.50.128.193 with HTTP; Thu, 27 Mar 2014 06:07:23 -0700 (PDT)
In-Reply-To: <CANEZrP37dO53Jp2rXpPqO3eMd6AWamtXaReq0arMfC=uY2aFUA@mail.gmail.com>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
<53340999.807@gmx.de>
<CAJna-HhmFya+3W67qQt0wMhW=B4vJvwdkr-5WnU+KEaKq7uaUA@mail.gmail.com>
<5334144A.9040600@gmx.de>
<CANEZrP37dO53Jp2rXpPqO3eMd6AWamtXaReq0arMfC=uY2aFUA@mail.gmail.com>
Date: Thu, 27 Mar 2014 10:07:23 -0300
Message-ID: <CA+vKqYegtXZ5cLsWo1hOsqaexNRtwL-mm6u=D0rpD--VQJSRtg@mail.gmail.com>
From: Matias Alejo Garcia <ematiu@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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
(ematiu[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1WTA1p-0003Nz-3s
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
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, 27 Mar 2014 13:07:32 -0000
On Thu, Mar 27, 2014 at 9:28 AM, Mike Hearn <mike@plan99.net> wrote:
> By the way, I just noticed that greenaddress.it is creating seeds that ha=
ve 24
> words instead of 12. Does anyone know what's up with that? They claim to =
be
> using BIP32 wallets so I wanted to see if they were using the default str=
ucture
> and if so, whether bitcoinj was compatible with it (before I switch to th=
e one
> discussed here). But it seems we fall at the first hurdle ...
>
They replied this on reddit: "Good question! We use 256-bit BIP39
seeds for our 512-bit extended HD wallet keypairs, as advised by
BIP32. We are aware that 128 is considered ok in Electrum but we
wanted to follow BIP32 spec, in particular because we are working with
hardware wallets that have been design with BIP32 in mind and wanted
to avoid any incompatibility issue."
http://www.reddit.com/r/Bitcoin/comments/20puhg/while_blockchaininfo_is_dow=
n_what_about_testing/cg5mr54
BTW, thanks for starting this thread. I am with the bitcore team,
working on a new multisig only wallet (Cosign).
The schema originally proposed be Mike (/m/cointype/reserved'/account'/chan=
ge/n
) seems flexible enough for our needs. I wonder, tough, if we can
agree also on a format to exchange the tips (n) of each branch on the
tree when the user export/backup the wallet, as Allen suggested.
On Wed, Mar 26, 2014 at 8:37 PM, Andreas Schildbach
<andreas@schildbach.de> wrote:
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.
Is the ideal schema that the user should be able to use two different
wallets at the same time? Does a wallet need to assume that derivate
keys could had been used already? That seems complicated. Maybe we
could add a /(hash of the wallet name)/ on the BIP32 path.
--
matias
--=20
Mat=C3=ADas Alejo Garcia
Skype/Twitter: @ematiu
Roads? Where we're going, we don't need roads!
|
