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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1V9zNe-0001t5-3N
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Aug 2013 15:22:30 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.47 as permitted sender)
client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f47.google.com;
Received: from mail-oa0-f47.google.com ([209.85.219.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V9zNd-0005WL-5z
for bitcoin-development@lists.sourceforge.net;
Thu, 15 Aug 2013 15:22:30 +0000
Received: by mail-oa0-f47.google.com with SMTP id g12so902989oah.20
for <bitcoin-development@lists.sourceforge.net>;
Thu, 15 Aug 2013 08:22:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.112.166 with SMTP id ir6mr25890723obb.25.1376580143783;
Thu, 15 Aug 2013 08:22:23 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.80.165 with HTTP; Thu, 15 Aug 2013 08:22:23 -0700 (PDT)
In-Reply-To: <CAJna-HiSUHSAREzGLxi0nUctmt4OoaAKC7txEruQG_AgwGa_Qw@mail.gmail.com>
References: <CABsx9T3DM72+8HgNWWZ2HaAgZMQGAPn87L9VVKdkbVkS7sd8Tg@mail.gmail.com>
<CANEZrP3bt40ThBcqWLfzuS5508mpbo4Z5qxh9AJs-FRrk0QJsA@mail.gmail.com>
<CAJna-HhS=iNcTcTzEm_GDtjzxbSTDJ0KvEjLvpnR_HngRYjHeA@mail.gmail.com>
<CANEZrP3-SV0=PB5rkXbAEKv1CFqfS4hjuBTY3YbU-yNGKde8tg@mail.gmail.com>
<CAJna-HiSUHSAREzGLxi0nUctmt4OoaAKC7txEruQG_AgwGa_Qw@mail.gmail.com>
Date: Thu, 15 Aug 2013 17:22:23 +0200
X-Google-Sender-Auth: K5krUkxQKjMxyxWrY2wsMpMSrHY
Message-ID: <CANEZrP2+8a4-tp39Cfoi2TvbfGAka3BgAWMdprfmG8rDc6deiw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: slush <slush@centrum.cz>
Content-Type: multipart/alternative; boundary=089e0153758079a77a04e3fe0af1
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1V9zNd-0005WL-5z
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Version 0.9 goals
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, 15 Aug 2013 15:22:30 -0000
--089e0153758079a77a04e3fe0af1
Content-Type: text/plain; charset=UTF-8
> Our plan is to add support for that into v1 firmware, but it also depends
> on readiness of surrounding infrastructure; mainly if there'll be support
> for payment protocol in multibit in the time of v1 release (I suppose that
> the Multibit will be the first wallet compatible with Trezor AND
> supporting payment protocol).
>
Yeah, OK. Let's see how much progress Gary makes. Supporting HD wallets is
the trickiest part and I don't know how much time I will have - the Android
RNG issue and getting bcj 0.10 released have sucked up a lot of my time
lately and I need to refocus on other things for a bit. But between the guy
who volunteered to do payment protocol, and Gary doing TrezorJ, and Matija
already having done the core algorithms, I'm hoping the only parts I'll
have to do are integrating the HD code with the core wallet code. Possibly
if we're running out of time I can do a real basic HD wallet implementation
that only iterates a key once and doesn't generate new keys for each
transaction, as that's really the trickiest part (because of the need for
lookahead/behind and memory bloat on phones).
--089e0153758079a77a04e3fe0af1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
Our plan is to add support for that into v1 firmware, but it also depends o=
n readiness of surrounding infrastructure; mainly if there'll be suppor=
t for payment protocol in multibit in the time of v1 release (I suppose tha=
t the Multibit will be the first wallet =C2=A0compatible with Trezor AND su=
pporting payment protocol).</div>
</div></blockquote><div><br></div><div>Yeah, OK. Let's see how much pro=
gress Gary makes. Supporting HD wallets is the trickiest part and I don'=
;t know how much time I will have - the Android RNG issue and getting bcj 0=
.10 released have sucked up a lot of my time lately and I need to refocus o=
n other things for a bit. But between the guy who volunteered to do payment=
protocol, and Gary doing TrezorJ, and Matija already having done the core =
algorithms, I'm hoping the only parts I'll have to do are integrati=
ng the HD code with the core wallet code. Possibly if we're running out=
of time I can do a real basic HD wallet implementation that only iterates =
a key once and doesn't generate new keys for each transaction, as that&=
#39;s really the trickiest part (because of the need for lookahead/behind a=
nd memory bloat on phones).</div>
</div></div></div>
--089e0153758079a77a04e3fe0af1--
|
