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
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alexy.kot.all@gmail.com>) id 1WLced-00020w-3C
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Mar 2014 18:04:23 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.128.181 as permitted sender)
client-ip=209.85.128.181; envelope-from=alexy.kot.all@gmail.com;
helo=mail-ve0-f181.google.com;
Received: from mail-ve0-f181.google.com ([209.85.128.181])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WLceN-0002P7-3e
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Mar 2014 18:04:23 +0000
Received: by mail-ve0-f181.google.com with SMTP id oy12so2980893veb.40
for <bitcoin-development@lists.sourceforge.net>;
Thu, 06 Mar 2014 10:04:01 -0800 (PST)
X-Received: by 10.52.137.143 with SMTP id qi15mr1000000vdb.39.1394129041583;
Thu, 06 Mar 2014 10:04:01 -0800 (PST)
MIME-Version: 1.0
Sender: alexy.kot.all@gmail.com
Received: by 10.59.0.38 with HTTP; Thu, 6 Mar 2014 10:03:20 -0800 (PST)
In-Reply-To: <lfa8pf$ckc$1@ger.gmane.org>
References: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
<CALDj+BZE1KtMGpMH3UHtxjN2vXxu39o_hAWPdg==KLsWpe1zqA@mail.gmail.com>
<lfa8pf$ckc$1@ger.gmane.org>
From: Alex Kotenko <alexykot@gmail.com>
Date: Thu, 6 Mar 2014 18:03:20 +0000
X-Google-Sender-Auth: qQkV-UzrJu2LSSCd9hm0WrV1_Xs
Message-ID: <CALDj+Bbe_rCfAoA1PDX5AXSvhYauObYh7Y6nAD3EbhfHX7exQg@mail.gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=bcaec52d55714b721304f3f3f645
X-Spam-Score: -0.6 (/)
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
(alexy.kot.all[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline
X-Headers-End: 1WLceN-0002P7-3e
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Instant / contactless payments
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: Thu, 06 Mar 2014 18:04:23 -0000
--bcaec52d55714b721304f3f3f645
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2014-03-06 16:46 GMT+00:00 Andreas Schildbach <andreas@schildbach.de>:
> Supporting Bluetooth is optional in the sense that if a wallet should
> not support it, you will still receive the transaction via the P2P
> network. So I'd say definately go for Bluetooth.
>
=E2=80=8BYes, it's part of the=E2=80=8B plan. Just again - I need to make s=
ure we support
all major wallets. And no other wallets actually support NFC by now, not
talking about bluetooth. So I imagine we will decide and implement together
some solution here, both on the wallet and POS sides, but I will have to
keep URI method and even QR codes for backwards compatibility, and wait for
other main wallets to accept innovations before we will be able to
completely switch to it.
As I said earlier - bluetooth support for my POS is not a problem, we can
plug it in easily and make it work. Support among all hardware/software and
polished user experience - this is a main thing here really.
I wonder about the receipt step -- are you generating a PDF on device
> and sending it via NFC? This is something that could be supported by the
> BIP70 payment protocol. We should try to avoid the second tap, its not
> intuitive.
>
=E2=80=8BNo, I'm generating it on server and sending only URL via NFC. I th=
ink this
area will change before we launch in production. Ideally I want =E2=80=8Bth=
e device
to be completely autonomous, controlled on site by the merchant, probably
with an app on his phone. But right now we have a backend server that gives
merchant a dashboard with device configuration control, transactions
history, daily reconciliation data and copies of receipts. So the PDF is
sent from that server.
=E2=80=8BWe should avoid second =E2=80=8Btap ideally, but we need to make s=
ure receipts and
payment proofs are usable and understandable for both payers and payees.
Right now a paperless PDF-only process is already a huge leap ahead
comparing to numerous paper receipts printed for each transaction by
existing POS systems.
Implementing proof of payment based on BIP70 payment request+transaction in
the blockchain+memo will require even bigger shift in the merchant's view
on how business runs. Also it will need additional software on his side to
actually be able to view and confirm these proofs of payment. In theory -
yes, BIP70 will create a way to implement proof of payment. In practice in
real life right now I don't see it viable, it will take time to adopt and
few intermediary steps like PDF based paperless process I've implemented.
--bcaec52d55714b721304f3f3f645
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2014-03-06 16:46 GMT+00:00 Andreas Schildbach <span dir=3D"ltr"><<a href=
=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@schildbach.de</=
a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div id=3D":1bd" class=3D"" style=3D"overflow:hidden">Supp=
orting Bluetooth is optional in the sense that if a wallet should<br>
not support it, you will still receive the transaction via the P2P<br>
network. So I'd say definately go for Bluetooth.</div></blockquote><div=
><div class=3D"gmail_default" style=3D"font-family:'courier new',mo=
nospace;color:rgb(0,51,0)">=E2=80=8BYes, it's part of the=E2=80=8B plan=
. Just again - I need to make sure we support all major wallets. And no oth=
er wallets actually support NFC by now, not talking about bluetooth. So I i=
magine we will decide and implement together some solution here, both on th=
e wallet and POS sides, but I will have to keep URI method and even QR code=
s for backwards compatibility, and wait for other main wallets to accept in=
novations before we will be able to completely switch to it.</div>
</div><div class=3D"gmail_default" style=3D"font-family:'courier new=
9;,monospace;color:rgb(0,51,0)">As I said earlier - bluetooth support for m=
y POS is not a problem, we can plug it in easily and make it work. Support =
among all hardware/software and polished user experience - this is a main t=
hing here really.</div>
<div class=3D"gmail_default" style=3D"font-family:'courier new',mon=
ospace;color:rgb(0,51,0)"><br></div><div>=C2=A0I wonder about the receipt s=
tep -- are you generating a PDF on device</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=3D":1bd" class=3D"" style=3D"overflow:hidden">
and sending it via NFC? This is something that could be supported by the<br=
>
BIP70 payment protocol. We should try to avoid the second tap, its not<br>
intuitive.</div></blockquote></div><div class=3D"gmail_default" style=3D"fo=
nt-family:'courier new',monospace;color:rgb(0,51,0)">=E2=80=8BNo, I=
'm generating it on server and sending only URL via NFC. I think this a=
rea will change before we launch in production. Ideally I want =E2=80=8Bthe=
device to be completely autonomous, controlled on site by the merchant, pr=
obably with an app on his phone. But right now we have a backend server tha=
t gives merchant a dashboard with device configuration control, transaction=
s history, daily reconciliation data and copies of receipts. So the PDF is =
sent from that server.</div>
<br><div class=3D"gmail_default" style=3D"font-family:'courier new'=
,monospace;color:rgb(0,51,0)">=E2=80=8BWe should avoid second =E2=80=8Btap =
ideally, but we need to make sure receipts and payment proofs are usable an=
d understandable for both payers and payees.</div>
<div class=3D"gmail_default" style=3D"font-family:'courier new',mon=
ospace;color:rgb(0,51,0)">Right now a paperless PDF-only process is already=
a huge leap ahead comparing to numerous paper receipts printed for each tr=
ansaction by existing POS systems.=C2=A0</div>
<div class=3D"gmail_default" style=3D"font-family:'courier new',mon=
ospace;color:rgb(0,51,0)">Implementing proof of payment based on BIP70 paym=
ent request+transaction in the blockchain+memo will require even bigger shi=
ft in the merchant's view on how business runs. Also it will need addit=
ional software on his side to actually be able to view and confirm these pr=
oofs of payment. In theory - yes, BIP70 will create a way to implement proo=
f of payment. In practice in real life right now I don't see it viable,=
it will take time to adopt and few intermediary steps like PDF based paper=
less process I've implemented.</div>
<br>
</div></div>
--bcaec52d55714b721304f3f3f645--
|
