1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WzoL0-0000vW-M7
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Jun 2014 14:38:14 +0000
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;
Received: from mail-oa0-f47.google.com ([209.85.219.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WzoKy-0007WB-9v
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Jun 2014 14:38:14 +0000
Received: by mail-oa0-f47.google.com with SMTP id n16so2199420oag.6
for <bitcoin-development@lists.sourceforge.net>;
Wed, 25 Jun 2014 07:38:06 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.52.77 with SMTP id r13mr8298320oeo.55.1403707086855; Wed,
25 Jun 2014 07:38:06 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Wed, 25 Jun 2014 07:38:06 -0700 (PDT)
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
X-Google-Sender-Auth: 3Pt1Y_yv6gfSCiOpO_UCV8XEt_w
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
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WzoKy-0007WB-9v
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bill Request Message - (another) Proposed
BIP 70 extension
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 25 Jun 2014 14:38:14 -0000
--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's not a big deal, bu=
t there's no reason both or all mechanisms can'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' 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 cer=
tainly scan some rectangle that'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--
|
