MIME-Version: 1.0
Sender: marek@palatinus.cz
In-Reply-To: <CACsn0cmsoS5riXAV7eWMfTFzSNwbjWEUNCa39m1MgKGxvRKCmg@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
	<20121128233619.GA6368@giles.gnomon.org.uk>
	<CACsn0cmsoS5riXAV7eWMfTFzSNwbjWEUNCa39m1MgKGxvRKCmg@mail.gmail.com>
From: slush <slush@centrum.cz>
Date: Thu, 29 Nov 2012 09:16:31 +0100
Message-ID: <CAJna-Hj-OVDA_YBG9HHhtPrfR96BhhyJxUL3W6wJ+9iUmKXF4A@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=14dae9cdc4f3503fa904cf9de8d8
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
	Invoices/Payments/Receipts
Precedence: list

--14dae9cdc4f3503fa904cf9de8d8
Content-Type: text/plain; charset=ISO-8859-1

Hi,

not sure if you already noticed, but I and my friends are actively working
on bitcoin hardware wallet. This should be pocket size device with
something like 256kB flash and 80 MHz CPU, talking with the computer over
USB. User will prepare transaction on the machine, send it to the device,
device shows target address on the display and user confirms it by pressing
the button.

We're trying to make bitcoin payments safe even on hacked computer. For
this reason we're also implementing SPV so device don't need to trust
computer with any kind of information. The biggest existing problem is that
user cannot be sure that the address displayed on computer screen is
correct and he's confirming valid address.

I don't have any solution for this problem yet. I just appreciate an
activity in payment protocol area, because it can (with some care) solve
this problem and my appeal si to keep all this simple. I'd be very happy
with simple payment protocol which can be implemented even on devices like
I'm working on, so device with few widely used certificates stored in the
memory will be able to display origin of the invoice and confirm its
validity.

slush


On Thu, Nov 29, 2012 at 1:30 AM, Watson Ladd <wbl@uchicago.edu> wrote:

> After doing more thinking, what about letting a spend sign more
> information associated with the transaction, such as a transaction ID
> provided by the merchant? This seems to solve a lot of the problems being
> put forward, with much less complexity.
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> VERIFY Test and improve your parallel project with help from experts
> and peers. http://goparallel.sourceforge.net
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--14dae9cdc4f3503fa904cf9de8d8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>not sure if you already noticed, but I and my friend=
s are actively working on bitcoin hardware wallet. This should be pocket si=
ze device with something like 256kB flash and 80 MHz CPU, talking with the =
computer over USB. User will prepare transaction on the machine, send it to=
 the device, device shows target address on the display and user confirms i=
t by pressing the button.</div>

<div><br></div><div>We&#39;re trying to make bitcoin payments safe even on =
hacked computer. For this reason we&#39;re also implementing SPV so device =
don&#39;t need to trust computer with any kind of information.=A0The bigges=
t existing problem is that user cannot be sure that the address displayed o=
n computer screen is correct and he&#39;s confirming valid address.</div>

<div><br></div><div>I don&#39;t have any solution for this problem yet. I j=
ust appreciate an activity in payment protocol area, because it can (with s=
ome care) solve this problem and my appeal si to keep all this simple. I=
9;d be very happy with simple payment protocol which can be implemented eve=
n on devices like I&#39;m working on, so device with few widely used certif=
icates stored in the memory will be able to display origin of the invoice a=
nd confirm its validity.</div>

<div><br></div><div>slush</div><div class=3D"gmail_extra"><br><br><div clas=
s=3D"gmail_quote">On Thu, Nov 29, 2012 at 1:30 AM, Watson Ladd <span dir=3D=
"ltr">&lt;<a href=3D"mailto:wbl@uchicago.edu" target=3D"_blank">wbl@uchicag=
o.edu</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">After doing more thinking, what about lettin=
g a spend sign more information associated with the transaction, such as a =
transaction ID provided by the merchant? This seems to solve a lot of the p=
roblems being put forward, with much less complexity.
<br>-----------------------------------------------------------------------=
-------<br>
Keep yourself connected to Go Parallel:<br>
VERIFY Test and improve your parallel project with help from experts<br>
and peers. <a href=3D"http://goparallel.sourceforge.net" target=3D"_blank">=
http://goparallel.sourceforge.net</a><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>
<br></blockquote></div><br></div>

--14dae9cdc4f3503fa904cf9de8d8--