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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <allen.piscitello@gmail.com>) id 1WTER5-0003iB-TR
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 17:49:51 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.52 as permitted sender)
client-ip=209.85.213.52;
envelope-from=allen.piscitello@gmail.com;
helo=mail-yh0-f52.google.com;
Received: from mail-yh0-f52.google.com ([209.85.213.52])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WTER4-0005f2-Gf
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 17:49:51 +0000
Received: by mail-yh0-f52.google.com with SMTP id c41so3928418yho.39
for <bitcoin-development@lists.sourceforge.net>;
Thu, 27 Mar 2014 10:49:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.131.19 with SMTP id l19mr4429736yhi.0.1395942585013;
Thu, 27 Mar 2014 10:49:45 -0700 (PDT)
Received: by 10.170.88.10 with HTTP; Thu, 27 Mar 2014 10:49:44 -0700 (PDT)
In-Reply-To: <CAPg+sBhbx5vy_hewAkFPaiXHzSMNH0qLhEYGjPmQMjR5StP-tw@mail.gmail.com>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
<F2C8C044-EF92-4CCE-9235-28CA7FCE3526@bitsofproof.com>
<CAJHLa0PPAsBLgsy0vgPpUp=UzeR_fWUEzFb5+xtmODEk4MGPVQ@mail.gmail.com>
<CAJfRnm7V6fgcj=TMfa2ZTYWOKtE5aoUT1xnVtKUSyriB=6cagQ@mail.gmail.com>
<CAPg+sBjwf1TcK1CGKVKFzYbV-78j8t-pav7=PEgG7Yqi6-yE7A@mail.gmail.com>
<53344FF8.7030204@gk2.sk>
<CAPg+sBhbx5vy_hewAkFPaiXHzSMNH0qLhEYGjPmQMjR5StP-tw@mail.gmail.com>
Date: Thu, 27 Mar 2014 12:49:44 -0500
Message-ID: <CAJfRnm7Leu7+e6XPm7RRa8SBZXZGycaRbEktVTE2FkGrPjq4vg@mail.gmail.com>
From: Allen Piscitello <allen.piscitello@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=20cf3010e96de81a3b04f59a3536
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
(allen.piscitello[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: 1WTER4-0005f2-Gf
Cc: Bitcoin Dev <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 17:49:52 -0000
--20cf3010e96de81a3b04f59a3536
Content-Type: text/plain; charset=ISO-8859-1
The benefit I see is avoiding reuse of keys between coins while not having
each wallet implementation have to know about each coin in order to scan
for transactions. Wallet X supports Doge and Bitcoin. If both used a
shared sequence of keys, say the first two end up Bitcoin, then 10 Doge,
then some more Bitcoin. If you took this seed to Wallet Y, which only
supports Bitcoin (either the wallet's support or what is installed on the
system it's being used), it will see a gap of 10 addresses, and presume no
more scanning with a 5 gap limit. The alternative is to reuse keys for
each coin.
It also seems like a solution might be to only expect interoperability on a
single sequence, and provide backups of each final sequence to use between
different wallet implementations. This allows flexibility in hierarchies
depending on needs and support of wallet, but allows sharing. The short
seed would only be useful for the same wallet, but sharing between wallets
would use the longer keys. That will give predictable behavior for users
(although less friendly) and lead to less errors.
-Allen
On Thu, Mar 27, 2014 at 11:28 AM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
> On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick@gk2.sk> wrote:
> > Cointype in path is for separation purposes, not for identification.
>
> I don't understand what that gains you.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--20cf3010e96de81a3b04f59a3536
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The benefit I see is avoiding reuse of keys between coins =
while not having each wallet implementation have to know about each coin in=
order to scan for transactions. =A0Wallet X supports Doge and Bitcoin. =A0=
If both used a shared sequence of keys, say the first two end up Bitcoin, t=
hen 10 Doge, then some more Bitcoin. =A0If you took this seed to Wallet Y, =
which only supports Bitcoin (either the wallet's support or what is ins=
talled on the system it's being used), it will see a gap of 10 addresse=
s, and presume no more scanning with a 5 gap limit. =A0The alternative is t=
o reuse keys for each coin.<div>
<br></div><div>It also seems like a solution might be to only expect intero=
perability on a single sequence, and provide backups of each final sequence=
to use between different wallet implementations. =A0This allows flexibilit=
y in hierarchies depending on needs and support of wallet, but allows shari=
ng. =A0The short seed would only be useful for the same wallet, but sharing=
between wallets would use the longer keys. =A0That will give predictable b=
ehavior for users (although less friendly) and lead to less errors.<br>
<div><div><br></div><div>-Allen</div></div></div></div><div class=3D"gmail_=
extra"><br><br><div class=3D"gmail_quote">On Thu, Mar 27, 2014 at 11:28 AM,=
Pieter Wuille <span dir=3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail.=
com" target=3D"_blank">pieter.wuille@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On Thu, Mar 27, 2014 at 5:21=
PM, Pavol Rusnak <<a href=3D"mailto:stick@gk2.sk">stick@gk2.sk</a>> =
wrote:<br>
> Cointype in path is for separation purposes, not for identification.<b=
r>
<br>
</div>I don't understand what that gains you.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Pieter<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
--20cf3010e96de81a3b04f59a3536--
|
