path: root/42/a011532e064578855831bc1e91774ecbf0bda4

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <alexy.kot.all@gmail.com>) id 1WN1pr-000700-Fe
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Mar 2014 15:09:47 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.176 as permitted sender)
	client-ip=209.85.220.176; envelope-from=alexy.kot.all@gmail.com;
	helo=mail-vc0-f176.google.com; 
Received: from mail-vc0-f176.google.com ([209.85.220.176])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WN1pp-0002ms-VA
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Mar 2014 15:09:47 +0000
Received: by mail-vc0-f176.google.com with SMTP id lc6so6501541vcb.7
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 10 Mar 2014 08:09:40 -0700 (PDT)
X-Received: by 10.220.95.139 with SMTP id d11mr5106648vcn.21.1394464180415;
	Mon, 10 Mar 2014 08:09:40 -0700 (PDT)
MIME-Version: 1.0
Sender: alexy.kot.all@gmail.com
Received: by 10.59.0.38 with HTTP; Mon, 10 Mar 2014 08:09:00 -0700 (PDT)
In-Reply-To: <20140308085242.GA5727@odo.localdomain>
References: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
	<CALDj+BZE1KtMGpMH3UHtxjN2vXxu39o_hAWPdg==KLsWpe1zqA@mail.gmail.com>
	<20140308085242.GA5727@odo.localdomain>
From: Alex Kotenko <alexykot@gmail.com>
Date: Mon, 10 Mar 2014 15:09:00 +0000
X-Google-Sender-Auth: ztkQznb82tNN-T7S7NZeVYZrzQ4
Message-ID: <CALDj+BYoYy8LWTgguj7FnrGMHuA5hgFdcFenBTdcxMuOwJ+tdA@mail.gmail.com>
To: Jan Vornberger <jan@uos.de>
Content-Type: multipart/alternative; boundary=001a11c2ae7620350e04f441fe5c
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: 1WN1pp-0002ms-VA
Cc: Bitcoin Dev <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: Mon, 10 Mar 2014 15:09:47 -0000

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

2014-03-08 8:52 GMT+00:00 Jan Vornberger <jan@uos.de>:
=E2=80=8B=E2=80=8B

> 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=3DDGOMIG9JUY8 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.
>
No, devices on this video are not on the same network, and even if they
would - I cannot control what =E2=80=8B=E2=80=8Bremote hosts my phone would=
 connect to, so
transaction may anyway travel around the globe before coming to the POS
even if they would be on one LAN.
As for transaction times - I'd say it varies. =E2=80=8BFrom my extensive te=
sting
most of transactions usually come through within 2-5 seconds, but roughly
one in ten transactions may take more time, sometimes much more time.


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.
>
=E2=80=8BYes, =E2=80=8BI'm certain about that we need to switch to BIP70 as=
ap. As I said
earlier - support among the wallets is the biggest problem here really.
Only Andreas' Wallet supports it right now AFAIK, and even in there it's
only as "LABS feature", so will be turned off for most of users.


In the context of this discussion, I would also like to share a video of
> a prototype system:
>
>   https://www.youtube.com/watch?v=3DmguRpvf3aMc
>
> 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.
>
Yes, I've seen this demonstration, I think it was on reddit about two
month=E2=80=8B=E2=80=8B ago. Looks interesting, but by that time most of my=
 client software
was already done, so I couldn't really use this.



> >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.

=E2=80=8BNFC
=E2=80=8Bas =E2=80=8B
back channel
=E2=80=8Bdefinitely =E2=80=8B
will not work
=E2=80=8B. Mike proposed something =E2=80=8Blike a threshold to define mini=
mal amount
available for spending without confirmation, but I don't see this thing
becoming widely used any time soon, and before that we will need to have
"confirm" button tap.


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.
>
Yes, this is a problem, I think bluetooth is offline on many devices, and
keeping it on all the time will harm security (if not real security, then
at least perceived by users) and also harm battery life, which will be seen
as huge problem by the users.
=E2=80=8BWould be great to be =E2=80=8Bable to control BT state automatical=
ly from within
the wallet app with user permission given once on installation time, but
not sure if it's possible in Android.



>
> -------------------------------------------------------------------------=
-----
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=3D122218951&iu=3D/4140/ostg=
.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a11c2ae7620350e04f441fe5c
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:&#39;cou=
rier new&#39;,monospace;color:rgb(0,51,0)"><span style=3D"font-family:arial=
;color:rgb(34,34,34)">2014-03-08 8:52 GMT+00:00 Jan Vornberger </span><span=
 dir=3D"ltr" style=3D"font-family:arial;color:rgb(34,34,34)">&lt;<a href=3D=
"mailto:jan@uos.de" target=3D"_blank">jan@uos.de</a>&gt;</span><span style=
=3D"font-family:arial;color:rgb(34,34,34)">:</span><br>



</div><div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#3=
9;,monospace;color:rgb(0,51,0)">=E2=80=8B=E2=80=8B</div><div class=3D"gmail=
_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">


On Thu, Mar 06, 2014 at 02:39:52PM +0000, Alex Kotenko wrote:<br>

&gt; Not sure if you&#39;ve seen it, but here is how we do NFC right now<br=
>
&gt; <a href=3D"http://www.youtube.com/watch?v=3DDGOMIG9JUY8" target=3D"_bl=
ank">http://www.youtube.com/watch?v=3DDGOMIG9JUY8</a> with XBTerminal.<br>
<br>
Very interesting, thanks for sharing! Are the two devices on the same<br>
wifi network in the demo? In my experience transaction propagation<br>
through the Bitcoin network takes a couple of seconds longer on average,<br=
>
so I&#39;m surprised it&#39;s that fast here.<br></blockquote><div class=3D=
"gmail_default" style=3D"font-family:&#39;courier new&#39;,monospace;color:=
rgb(0,51,0)">No, devices on this video are not on the same network, and eve=
n if they would - I cannot control what =E2=80=8B=E2=80=8Bremote hosts my p=
hone would connect to, so transaction may anyway travel around the globe be=
fore coming to the POS even if they would be on one LAN.</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)">As for transaction times - I&#39;d say it varies.=
 =E2=80=8BFrom my extensive testing most of transactions usually come throu=
gh within 2-5 seconds, but roughly one in ten transactions may take more ti=
me, sometimes much more time. =C2=A0</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)"><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex">



You probably share this view, but I just wanted to repeat, that from my<br>
experiments, I think that sending the transaction only over the Bitcoin<br>
network should be a rarely-used fallback. It usually takes a little<br>
longer than you would like for a POS solution and every so often you<br>
don&#39;t get the transaction at all until the next block. And then what do=
<br>
you do? Maybe you would need to ask the customer to pay again, to get<br>
things done now, and put the previous transaction in some kind of refund<br=
>
mode, where - when you finally get it - you send it back somewhere. But<br>
it&#39;s really a problematic corner case - but yet it will happen<br>
occasionally with network-only propagation.<br></blockquote><div><div class=
=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,monospace;col=
or:rgb(0,51,0)">=E2=80=8BYes, =E2=80=8BI&#39;m certain about that we need t=
o switch to BIP70 asap. As I said earlier - support among the wallets is th=
e biggest problem here really. Only Andreas&#39; Wallet supports it right n=
ow AFAIK, and even in there it&#39;s only as &quot;LABS feature&quot;, so w=
ill be turned off for most of users.</div>


</div><div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#3=
9;,monospace;color:rgb(0,51,0)"><span style=3D"color:rgb(34,34,34);font-fam=
ily:arial"><br></span></div><div class=3D"gmail_default" style=3D"font-fami=
ly:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">


<span style=3D"color:rgb(34,34,34);font-family:arial"><br></span></div><blo=
ckquote 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;paddi=
ng-left:1ex">



In the context of this discussion, I would also like to share a video of<br=
>
a prototype system:<br>
<br>
=C2=A0 <a href=3D"https://www.youtube.com/watch?v=3DmguRpvf3aMc" target=3D"=
_blank">https://www.youtube.com/watch?v=3DmguRpvf3aMc</a><br>
<br>
Here shown is the (currently no longer working) Bridgewalker client, but<br=
>
it is also fully compatible with Andreas&#39; wallet. The client picks up<b=
r>
the payment details via NFC (as a Bitcoin URI - could and should be<br>
updated to use payment protocol) and transmits a copy of the transaction<br=
>
via Bluetooth (using the simple convention first implemented by<br>
Andreas). One optimization I did in the Bridgewalker client is, that it<br>
already opens the Bluetooth connection when presenting the user with the<br=
>
confirmation dialog. This results in a little additional speed-up, as<br>
the connection is already &quot;warmed up&quot;, when the user confirms. Al=
l code<br>
of this prototype is open source, as is the Bridgewalker client.<br></block=
quote><div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#3=
9;,monospace;color:rgb(0,51,0)">Yes, I&#39;ve seen this demonstration, I th=
ink it was on reddit about two month=E2=80=8B=E2=80=8B ago. Looks interesti=
ng, but by that time most of my client software was already done, so I coul=
dn&#39;t really use this.</div>


<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex">
&gt;From my testing, I can say that NFC for getting the payment details +<b=
r>
Bluetooth for transmitting the transaction back works well. I&#39;m a bit<b=
r>
skeptical about using NFC also for the back-channel, but maybe for cases<br=
>
where there is no additional user confirmation it could work.</blockquote><=
div><font color=3D"#003300" face=3D"courier new, monospace">=E2=80=8BNFC </=
font><div class=3D"gmail_default" style=3D"color:rgb(0,51,0);font-family:&#=
39;courier new&#39;,monospace;display:inline">


=E2=80=8Bas =E2=80=8B</div><font color=3D"#003300" face=3D"courier new, mon=
ospace">back channel </font><div class=3D"gmail_default" style=3D"color:rgb=
(0,51,0);font-family:&#39;courier new&#39;,monospace;display:inline">=E2=80=
=8Bdefinitely =E2=80=8B</div><font color=3D"#003300" face=3D"courier new, m=
onospace">will not work</font><div class=3D"gmail_default" style=3D"display=
:inline">


<font color=3D"#003300" face=3D"courier new, monospace">=E2=80=8B. Mike pro=
posed something =E2=80=8Blike a=C2=A0threshold=C2=A0to define minimal amoun=
t available for spending without confirmation, but I don&#39;t see this thi=
ng becoming widely used any time soon, and before that we will need to have=
 &quot;confirm&quot; button tap.</font></div>


</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
One problem with Bluetooth I see is, that it seems to be mostly turned<br>
off by users and many seem to perceive it as &quot;insecure&quot;, to have =
it<br>
active, as a result of earlier Bluetooth hacks. So I&#39;m not sure if that=
<br>
will turn out to be a problem for usability when rolled-out in practice.<br=
></blockquote><div><div class=3D"gmail_default" style=3D"font-family:&#39;c=
ourier new&#39;,monospace;color:rgb(0,51,0)">Yes, this is a problem, I thin=
k bluetooth is offline on many devices, and keeping it on all the time will=
 harm security (if not real security, then at least perceived by users) and=
 also harm battery life, which will be seen as huge problem by the users.</=
div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)">=E2=80=8BWould be great to be =E2=80=8Bable to co=
ntrol BT state automatically from within the wallet app with user permissio=
n given once on installation time, but not sure if it&#39;s possible in And=
roid.=C2=A0</div>


</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex">
---------------------------------------------------------------------------=
---<br>
Subversion Kills Productivity. Get off Subversion &amp; Make the Move to Pe=
rforce.<br>
With Perforce, you get hassle-free workflows. Merge that actually works.<br=
>
Faster operations. Version large binaries. =C2=A0Built-in WAN optimization =
and the<br>
freedom to use Git, Perforce or both. Make the move to Perforce.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D122218951&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D122218951&amp;iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div>

--001a11c2ae7620350e04f441fe5c--