Received-SPF: pass (sog-mx-3.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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CADE3-jBdEM4YnBKue6_Q_ZDitUZ7aSGGqrYg6X=N0c0PC1az+g@mail.gmail.com>
References: <CADE3-jBoZCaRgx=P3AzKGPDCHJW0Z1KLmy_02ke4Jh+RTETqkQ@mail.gmail.com>
	<CANEZrP3_pKzuS6mWL4TNAQcEcz_6wwzUX8LPtmdv2XUJSvDKuw@mail.gmail.com>
	<CADE3-jBdEM4YnBKue6_Q_ZDitUZ7aSGGqrYg6X=N0c0PC1az+g@mail.gmail.com>
Date: Wed, 25 Jun 2014 16:38:06 +0200
Message-ID: <CANEZrP19T4q73Y9Y4x2gyD26MK5CPkuDdd12-Ewr_DhpGsGzng@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Paul Goldstein <paul@skydroid.net>
Content-Type: multipart/alternative; boundary=001a11330d0247e60004fcaa0654
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bill Request Message - (another) Proposed
 BIP 70 extension
Precedence: list

--001a11330d0247e60004fcaa0654
Content-Type: text/plain; charset=UTF-8

Alright. I still tend to think it's not a big deal, but there's no reason
both or all mechanisms can't co-exist.

BTW: a QR code next to a cash register can be fixed i.e. printed on paper
when using BIP70. The PoS would upload payment details to the server and
the URL for that particular PoS unit would then serve it when the user
scans the QR code. Alternatively, Andreas' work on Bluetooth may be more
appropriate: the QR code can contain the BT MAC of the device and the
payment request is downloaded that way. That's already implemented! I still
feel that if a seller can scan a users phone, the users phone can certainly
scan some rectangle that's physically near by the sales counter.

The other nice thing about that approach is the QRcode can also be an NFC
tag i.e. have the tag behind it with a little icon in the middle of the QR
code to indicate that touching works as well as scanning.

One project I keep wanting to play with is making these little NFC-QRcode
hybrids and a simple PoS app to go with them. But no time, alas ....

--001a11330d0247e60004fcaa0654
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Alright. I still tend to think it&#39;s not a big deal, bu=
t there&#39;s no reason both or all mechanisms can&#39;t co-exist.<div><br>=
</div><div>BTW: a QR code next to a cash register can be fixed i.e. printed=
 on paper when using BIP70. The PoS would upload payment details to the ser=
ver and the URL for that particular PoS unit would then serve it when the u=
ser scans the QR code. Alternatively, Andreas&#39; work on Bluetooth may be=
 more appropriate: the QR code can contain the BT MAC of the device and the=
 payment request is downloaded that way. That&#39;s already implemented! I =
still feel that if a seller can scan a users phone, the users phone can cer=
tainly scan some rectangle that&#39;s physically near by the sales counter.=
</div>
<div><br></div><div>The other nice thing about that approach is the QRcode =
can also be an NFC tag i.e. have the tag behind it with a little icon in th=
e middle of the QR code to indicate that touching works as well as scanning=
.</div>
<div><br></div><div>One project I keep wanting to play with is making these=
 little NFC-QRcode hybrids and a simple PoS app to go with them. But no tim=
e, alas ....</div></div>

--001a11330d0247e60004fcaa0654--