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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Version 0.9 goals
Precedence: list

--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&#39;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&#39;s see how much pro=
gress Gary makes. Supporting HD wallets is the trickiest part and I don&#39=
;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&#39;m hoping the only parts I&#39;ll have to do are integrati=
ng the HD code with the core wallet code. Possibly if we&#39;re running out=
 of time I can do a real basic HD wallet implementation that only iterates =
a key once and doesn&#39;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--