From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WLWRj-0005n4-S1 for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 11:26:39 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; envelope-from=gcbd-bitcoin-development@m.gmane.org; helo=plane.gmane.org; Received: from plane.gmane.org ([80.91.229.3]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WLWRi-0007Dq-HQ for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 11:26:39 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WLWRb-0007c0-Pb for bitcoin-development@lists.sourceforge.net; Thu, 06 Mar 2014 12:26:31 +0100 Received: from f052204080.adsl.alicedsl.de ([78.52.204.80]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Mar 2014 12:26:31 +0100 Received: from andreas by f052204080.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 06 Mar 2014 12:26:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: bitcoin-development@lists.sourceforge.net From: Andreas Schildbach Date: Thu, 06 Mar 2014 12:26:20 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: f052204080.adsl.alicedsl.de User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: X-Spam-Score: -0.4 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.91.229.3 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.1 DKIM_ADSP_ALL No valid author signature, domain signs all mail -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1WLWRi-0007Dq-HQ Subject: Re: [Bitcoin-development] Instant / contactless payments 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, 06 Mar 2014 11:26:40 -0000 I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick up the phone the connection breaks. It's ok if some people decide to let the app do risk analysis, but you cannot force it onto users by picking a protocol that cannot deal with manual verification. Users should always have the choice to verify their payment without time pressure and by holding the device of their choice at their individual viewing distance. Besides, how do you plan to risk-analyse the memo field? In current phone implementations, the screen must be on already for NFC to be active. Also it must be unlocked, although I certainly hope future OSes will allow payment apps on the lock screen, just like they allow music players. > To get the very fast light feel the actual contact period has to be > quite short, so I bet we'd need to optimise the bootup process of the > Android wallet app. It's already very short if you can do without Android Beam, e.g. on Android 2.3. I'd say <200 ms for an BIP21 payment request. Bootup of the app and everything else happens after -- no need to continue contact. Indeed most of the bootup time goes into loading complex wallets. Our long standing plans to clean up the wallet and archieve transactions should help. Also, if Bitcoin catches on the app will just stay in memory. The most obvious optimization to speed up signature checking is to make it lazy. The user can already inspect the payment while signatures are being checked. Even transaction signing could already happen in advance, if it can be made sure that no signed transaction "escapes" the dialog without the users consent. Even the current ~10 second roundtrip is a huge improvement to the status quo. I recently tried to buy a subway ticket and it took me 7 full minutes (just for the payment process)!