From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Te0LL-00030O-LS for bitcoin-development@lists.sourceforge.net; Thu, 29 Nov 2012 09:23:39 +0000 X-ACL-Warn: Received: from mail-vb0-f47.google.com ([209.85.212.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Te0LH-0002uX-J8 for bitcoin-development@lists.sourceforge.net; Thu, 29 Nov 2012 09:23:39 +0000 Received: by mail-vb0-f47.google.com with SMTP id e21so13006533vbm.34 for ; Thu, 29 Nov 2012 01:23:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :x-gm-message-state; bh=5PReLGniW0tgAL7rxg/8VfU45sa2HDk/AQwhkr8yb/w=; b=Evj61Wp4VeuGrZIRESkzOTaYsk7bZMakblntWiAg6fd4sOvaRxDAP9BGXYhhaRoE6W k0IMPmZDgA3eyCtckUFqakY0ANGOc1OICwLC3lk+k2QKsLdJx0AFnDGZ4F50fSIrp8Q8 YKFfxramduShmmCEQQgIj3HOEwyrg5HLN+3FxZVe2veT0sCTprrLfC5SJPbdrOjijlat zQFNwbJjvHKSmT9WmOB4JpA0onzZkmpz9pNptPk6r+ZzXPOb07dM9a5LmFcZVAaHdMib D9a7DB2S2q31kt5ZXU1c0Sbu00oFkl6jrLOGxWc2+xPMQgzWk0X88ad30qGtl8QniqWx 8Zrg== Received: by 10.220.231.138 with SMTP id jq10mr30979901vcb.29.1354177021230; Thu, 29 Nov 2012 00:17:01 -0800 (PST) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.58.117.103 with HTTP; Thu, 29 Nov 2012 00:16:31 -0800 (PST) In-Reply-To: References: <20121128233619.GA6368@giles.gnomon.org.uk> From: slush Date: Thu, 29 Nov 2012 09:16:31 +0100 X-Google-Sender-Auth: yEjw8eSNi9cXHgrSDWsZmslMz68 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=14dae9cdc4f3503fa904cf9de8d8 X-Gm-Message-State: ALoCoQl0l8WBE94nRgUqaqSc1z2uZlteWFQ8ebpoMDpTMTUwIqkvF6XbQnZbrhlrRn4XAlpj+41D X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Te0LH-0002uX-J8 Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts 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, 29 Nov 2012 09:23:39 -0000 --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 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,

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.

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.=A0The bigges= t existing problem is that user cannot be sure that the address displayed o= n computer screen is correct and he's confirming valid address.

I don'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'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.

slush


On Thu, Nov 29, 2012 at 1:30 AM, Watson Ladd <wbl@uchicag= o.edu> wrote:
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.
-----------------------------------------------------------------------= -------
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--14dae9cdc4f3503fa904cf9de8d8--