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 1WMDLN-0004Xq-59 for bitcoin-development@lists.sourceforge.net; Sat, 08 Mar 2014 09:14:57 +0000 X-ACL-Warn: Received: from vm135.rz.uni-osnabrueck.de ([131.173.16.10] helo=smtp-auth.serv.Uni-Osnabrueck.DE) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WMDLL-0007Ug-9q for bitcoin-development@lists.sourceforge.net; Sat, 08 Mar 2014 09:14:57 +0000 Received: from msmtp-using-host (95-91-126-11-dynip.superkabel.de [95.91.126.11]) (authenticated bits=0) by smtp-auth.serv.Uni-Osnabrueck.DE (8.13.8/8.13.8) with ESMTP id s288qp7V019547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 8 Mar 2014 09:52:52 +0100 Date: Sat, 8 Mar 2014 09:52:42 +0100 From: Jan Vornberger To: Bitcoin Dev Message-ID: <20140308085242.GA5727@odo.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.8.84216 (Univ. Osnabrueck) X-PMX-Spam: Gauge=X, Probability=10%, Report= TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, ECARD_KNOWN_DOMAINS 0, RDNS_GENERIC_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __USER_AGENT 0 X-PMX-Spam-Level: X X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1WMDLL-0007Ug-9q 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: Sat, 08 Mar 2014 09:14:57 -0000 On Thu, Mar 06, 2014 at 02:39:52PM +0000, Alex Kotenko wrote: > Not sure if you've seen it, but here is how we do NFC right now > http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal. Very interesting, thanks for sharing! Are the two devices on the same wifi network in the demo? In my experience transaction propagation through the Bitcoin network takes a couple of seconds longer on average, so I'm surprised it's that fast here. You probably share this view, but I just wanted to repeat, that from my experiments, I think that sending the transaction only over the Bitcoin network should be a rarely-used fallback. It usually takes a little longer than you would like for a POS solution and every so often you don't get the transaction at all until the next block. And then what do you do? Maybe you would need to ask the customer to pay again, to get things done now, and put the previous transaction in some kind of refund mode, where - when you finally get it - you send it back somewhere. But it's really a problematic corner case - but yet it will happen occasionally with network-only propagation. In the context of this discussion, I would also like to share a video of a prototype system: https://www.youtube.com/watch?v=mguRpvf3aMc Here shown is the (currently no longer working) Bridgewalker client, but it is also fully compatible with Andreas' wallet. The client picks up the payment details via NFC (as a Bitcoin URI - could and should be updated to use payment protocol) and transmits a copy of the transaction via Bluetooth (using the simple convention first implemented by Andreas). One optimization I did in the Bridgewalker client is, that it already opens the Bluetooth connection when presenting the user with the confirmation dialog. This results in a little additional speed-up, as the connection is already "warmed up", when the user confirms. All code of this prototype is open source, as is the Bridgewalker client. >From my testing, I can say that NFC for getting the payment details + Bluetooth for transmitting the transaction back works well. I'm a bit skeptical about using NFC also for the back-channel, but maybe for cases where there is no additional user confirmation it could work. One problem with Bluetooth I see is, that it seems to be mostly turned off by users and many seem to perceive it as "insecure", to have it active, as a result of earlier Bluetooth hacks. So I'm not sure if that will turn out to be a problem for usability when rolled-out in practice.