From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Thu, 15 Aug 2013 17:22:23 +0200 X-Google-Sender-Auth: K5krUkxQKjMxyxWrY2wsMpMSrHY Message-ID: From: Mike Hearn To: slush 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

=
= 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).

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).
--089e0153758079a77a04e3fe0af1--