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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
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 1WLZTT-0008Vd-Mr
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Mar 2014 14:40:39 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.173 as permitted sender)
client-ip=209.85.220.173; envelope-from=alexy.kot.all@gmail.com;
helo=mail-vc0-f173.google.com;
Received: from mail-vc0-f173.google.com ([209.85.220.173])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WLZTS-0005WL-L2
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Mar 2014 14:40:39 +0000
Received: by mail-vc0-f173.google.com with SMTP id ld13so2685294vcb.32
for <bitcoin-development@lists.sourceforge.net>;
Thu, 06 Mar 2014 06:40:33 -0800 (PST)
X-Received: by 10.58.133.15 with SMTP id oy15mr5420523veb.19.1394116833148;
Thu, 06 Mar 2014 06:40:33 -0800 (PST)
MIME-Version: 1.0
Sender: alexy.kot.all@gmail.com
Received: by 10.59.0.38 with HTTP; Thu, 6 Mar 2014 06:39:52 -0800 (PST)
In-Reply-To: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
References: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
From: Alex Kotenko <alexykot@gmail.com>
Date: Thu, 6 Mar 2014 14:39:52 +0000
X-Google-Sender-Auth: _94VRkk9BvRcOsJm0mLjyNHjOuA
Message-ID: <CALDj+BZE1KtMGpMH3UHtxjN2vXxu39o_hAWPdg==KLsWpe1zqA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b6d9f829d84ea04f3f11e7f
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
X-Headers-End: 1WLZTS-0005WL-L2
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 14:40:39 -0000
--047d7b6d9f829d84ea04f3f11e7f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Mike
Not sure if you've seen it, but here is how we do NFC right now
http://www.youtube.com/watch?v=3DDGOMIG9JUY8 with XBTerminal.
For now this is just an NDEF URI message with Bitcoin URI inside, and then
transaction itself propagated to the network by the phone using it's own
Internet connection. Far not ideal, but even this is supported only by
Andreas' Wallet, so we cannot move ahead alot really until other wallets
will have some support in this area.
As you see - it's taking just few seconds, most of which is manual payment
confirmation. Btw, ignore my first screen tap, where I'm selecting wallets
- it's an unlikely thing to happen IRL to have several wallets installed at
the same time.
=E2=80=8BAlso, I think many people may not know about Oyster cards, so this=
might
need little bit of explanation. And btw, have you been to London lately?
Oyster readers now accept contactless cards directly along with Oyster
cards itself. I wonder if eventually in future we could add bitcoin support
into that system directly, without hardware replacements.
I cannot put much into the actual protocol discussion, but I'm happy to
provide feedback on the side of actual POS implementation needed and
testbase if required.
Have an =E2=80=8Bidea - it's a good thing to cap confirmationless payments,=
but the
actual cap value definition can be tricky considering Bitcoin volatility.
Inless you want to tie it to some external price definition thirdparty
service it could be tied to transaction fees. I mean - if with Bitcoin v0.9
transaction fees will become really floating, and it should eventually
reach equilibrium that will reflect some real world value. Probably a tiny
value, but probably also rather stable value. So confirmationless payment
cap may be defined as <current_average_transaction_fee>x10000.
--047d7b6d9f829d84ea04f3f11e7f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:'cou=
rier new',monospace;color:rgb(0,51,0)">Hi Mike=C2=A0</div><div class=3D=
"gmail_default" style=3D"font-family:'courier new',monospace;color:=
rgb(0,51,0)">
<br></div><div class=3D"gmail_default" style=3D"font-family:'courier ne=
w',monospace;color:rgb(0,51,0)"><br></div><div class=3D"gmail_default" =
style=3D"font-family:'courier new',monospace;color:rgb(0,51,0)">Not=
sure if you've seen it, but here is how we do NFC right now=C2=A0<a hr=
ef=3D"http://www.youtube.com/watch?v=3DDGOMIG9JUY8">http://www.youtube.com/=
watch?v=3DDGOMIG9JUY8</a> with XBTerminal.=C2=A0</div>
<div class=3D"gmail_default" style=3D"font-family:'courier new',mon=
ospace;color:rgb(0,51,0)">For now this is just an NDEF URI message with Bit=
coin URI inside, and then transaction itself propagated to the network by t=
he phone using it's own Internet connection. Far not ideal, but even th=
is is supported only by Andreas' Wallet, so we cannot move ahead alot r=
eally until other wallets will have some support in this area.</div>
<div class=3D"gmail_default" style=3D"font-family:'courier new',mon=
ospace;color:rgb(0,51,0)">As you see - it's taking just few seconds, mo=
st of which is manual payment confirmation. Btw, ignore my first screen tap=
, where I'm selecting wallets - it's an unlikely thing to happen IR=
L to have several wallets installed at the same time.</div>
<div class=3D"gmail_default" style=3D"font-family:'courier new',mon=
ospace;color:rgb(0,51,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:'courier new',monospace;color:rgb(0,51,0)">=E2=80=8BAlso=
, I think many people may not know about Oyster cards, so this might need l=
ittle bit of explanation. And btw, have you been to London lately? Oyster r=
eaders now accept contactless cards directly along with Oyster cards itself=
. I wonder if eventually in future we could add bitcoin support into that s=
ystem directly, without hardware replacements.<br>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div =
class=3D"gmail_default" style=3D"font-family:'courier new',monospac=
e;color:rgb(0,51,0)">I cannot put much into the actual protocol discussion,=
but I'm happy to provide feedback on the side of actual POS implementa=
tion needed and testbase if=C2=A0required.</div>
<div><br></div><div><div class=3D"gmail_default" style=3D"font-family:'=
courier new',monospace;color:rgb(0,51,0)">Have an =E2=80=8Bidea - it=
9;s a good thing to cap confirmationless payments, but the actual cap value=
definition can be tricky considering Bitcoin volatility. Inless you want t=
o tie it to some external price definition thirdparty service it could be t=
ied to transaction fees. I mean - if with Bitcoin v0.9 transaction fees wil=
l become really floating, and it should eventually reach equilibrium that w=
ill reflect some real world value. Probably a tiny value, but probably=C2=
=A0also=C2=A0rather stable value. So confirmationless payment cap may be de=
fined as <current_average_transaction_fee>x10000.</div>
</div></div><div class=3D"gmail_extra"><br></div></div>
--047d7b6d9f829d84ea04f3f11e7f--
|
