path: root/2a/2f11489249d15eb8b3535d218555288d39f8df

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	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 1WQzui-0003Ek-O9
	for bitcoin-development@lists.sourceforge.net;
	Fri, 21 Mar 2014 13:55:12 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.128.176 as permitted sender)
	client-ip=209.85.128.176; envelope-from=alexy.kot.all@gmail.com;
	helo=mail-ve0-f176.google.com; 
Received: from mail-ve0-f176.google.com ([209.85.128.176])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WQzug-000254-Ph
	for bitcoin-development@lists.sourceforge.net;
	Fri, 21 Mar 2014 13:55:12 +0000
Received: by mail-ve0-f176.google.com with SMTP id cz12so2586203veb.35
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 21 Mar 2014 06:55:05 -0700 (PDT)
X-Received: by 10.221.37.1 with SMTP id tc1mr7648805vcb.32.1395410105281; Fri,
	21 Mar 2014 06:55:05 -0700 (PDT)
MIME-Version: 1.0
Sender: alexy.kot.all@gmail.com
Received: by 10.59.0.38 with HTTP; Fri, 21 Mar 2014 06:54:25 -0700 (PDT)
In-Reply-To: <lgh1q8$1dc$1@ger.gmane.org>
References: <lc5hmg$1jh$1@ger.gmane.org> <leuunm$tjk$1@ger.gmane.org>
	<CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>
	<CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>
	<lge7lv$3mf$1@ger.gmane.org>
	<CALDj+BZRsXnU5w=1B+01PDfMPY-7zqU3GP_52vr9wknEdTJ59Q@mail.gmail.com>
	<lgh1q8$1dc$1@ger.gmane.org>
From: Alex Kotenko <alexykot@gmail.com>
Date: Fri, 21 Mar 2014 13:54:25 +0000
X-Google-Sender-Auth: Tx1bHUHo7I7XbjmuLbSin7Avhnc
Message-ID: <CALDj+Bb=CR1pL0Ze1M6k22wfQM1bL6-w+EyipJQWc1OHhAY0rg@mail.gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=001a11334c38a430fd04f51e3be8
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: 1WQzug-000254-Ph
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face 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: Fri, 21 Mar 2014 13:55:12 -0000

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

2014-03-21 9:47 GMT+00:00 Andreas Schildbach <andreas@schildbach.de>:

> On 03/20/2014 05:14 PM, Alex Kotenko wrote:
>
> > Hmm, if we're inventing an URI for bluetooth, I'd rather follow existin=
g
> > URI's patterns. BT is strictly point-to-point connection, so BT MAC
> > should be considered as server address, and payment request ID can be
> > considered as request path. Probably "bt:<bt-mac>/=E2=80=8B
> > <random_id_of_payment_request>" would be more usual and easily
> > understandable.
>
> Agreed. I used the dash because I feared a slash would need to be
> escaped if used in an URL parameter.
>
=E2=80=8BIt will need to be =E2=80=8Bescaped, but HTTP URLs used in BIP72 h=
ave it already,
so don't see why we should bother.



> > I wonder how complex it would be to implement HTTP-over-Bluetooth. Not
> > like I'm willing to do that now, but HTTP is well known and proven to b=
e
> > quite good for tasks like this, so in theory it would be handy to have
> > such capacities in here.
>
> Thought of that as well. On the other hand, HTTP might be overkill and
> we inherit its potential downsides as well.
>
=E2=80=8BIt definitely is an overkill. Don't think we should do it now unle=
ss we
will see later during implementation that we really have to.



> >     Well, do we need to be compatible? If the dev community decides
> Base43
> >     PR QR's (or whatever other self-contained format) is the way to go,
> we
> >     just implement, roll it out and use it.
> >
> > My PoS needs to be compatible with BIP21, as when I'm presenting QR cod=
e
> > or sending NFC message - I have no way to tell what wallet/phone is =E2=
=80=8B=E2=80=8Bon
> > the accepting side, so I have to be compatible to existing widely
> > supported technologies.
>
> Agreed. All I wanted to say support for QR is still small enough that we
> might be able to switch to an incompatible standard. If we're determined
> that is.

Ok. Btw, I've tested =E2=80=8BQR possibilities on my PoS screen, in binary =
mode
it's limited to about 600 chars, so really I can include only unsigned and
rather short payment request. Signed requests longer than few hundred bytes
will not work.



> > =E2=80=8BWell, yes, it would be less efficient than base43. But did you
> > calculate how much less? =E2=80=8BIt's a compatible and already widely =
used way
> > and loosing compatibility needs to have serious reasons, so would be
> > great to know exact figures here.
>
> Base 64 via binary QR:   64 chars / 256 chars
>                          =3D=3D> 6 bit / 8 bit =3D 0.75
>
> Base 43 via alphanum QR: 43 chars / 45 chars
>                          =3D=3D> 5.43 bit / 5.49 bit =3D 0.99
>
> That would be efficiency in terms of PR data size vs. amount space used
> in a QR code. Of course, the visual QR encoding also plays a role, for
> example its size is increased in discrete steps.
>
Ok, so base43-aphanum is winning about a quarter of capacity against
base64-binary. I probably will skip this anyway and go with bluetooth URI
scheme we've just agreed + old style payments over p2p network as fallback.
So no payment requests in QR codes at all from my side.




>
>
>
>
> -------------------------------------------------------------------------=
-----
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and thei=
r
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a11334c38a430fd04f51e3be8
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:courier =
new,monospace;color:#003300"><br></div><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">2014-03-21 9:47 GMT+00:00 Andreas Schildbach <span dir=3D=
"ltr">&lt;<a href=3D"mailto:andreas@schildbach.de" target=3D"_blank">andrea=
s@schildbach.de</a>&gt;</span>:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 03/20/2014 05:14 PM, Alex Kotenko wrote:<=
br>
<br>
&gt; Hmm, if we&#39;re inventing an URI for bluetooth, I&#39;d rather follo=
w existing<br>
&gt; URI&#39;s patterns. BT is strictly point-to-point connection, so BT MA=
C<br>
&gt; should be considered as server address, and payment request ID can be<=
br>
&gt; considered as request path. Probably &quot;bt:&lt;bt-mac&gt;/=E2=80=8B=
<br>
&gt; &lt;random_id_of_payment_request&gt;&quot; would be more usual and eas=
ily<br>
&gt; understandable.<br>
<br>
Agreed. I used the dash because I feared a slash would need to be<br>
escaped if used in an URL parameter.<br></blockquote><div><div class=3D"gma=
il_default" style=3D"font-family:&#39;courier new&#39;,monospace;color:rgb(=
0,51,0)">=E2=80=8BIt will need to be =E2=80=8Bescaped, but HTTP URLs used i=
n BIP72 have it already, so don&#39;t see why we should bother.</div>


<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; I wonder how complex it would be to implement HTTP-over-Bluetooth. Not=
<br>
&gt; like I&#39;m willing to do that now, but HTTP is well known and proven=
 to be<br>
&gt; quite good for tasks like this, so in theory it would be handy to have=
<br>
&gt; such capacities in here.<br>
<br>
Thought of that as well. On the other hand, HTTP might be overkill and<br>
we inherit its potential downsides as well.<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=8BIt definitely is an overkill. Don&#39;t think we s=
hould do it now unless we will see later during implementation that we real=
ly have to.</div>


<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; =C2=A0 =C2=A0 Well, do we need to be compatible? If the dev community =
decides Base43<br>
&gt; =C2=A0 =C2=A0 PR QR&#39;s (or whatever other self-contained format) is=
 the way to go, we<br>
&gt; =C2=A0 =C2=A0 just implement, roll it out and use it.<br>
&gt;<br>
&gt; My PoS needs to be compatible with BIP21, as when I&#39;m presenting Q=
R code<br>
&gt; or sending NFC message - I have no way to tell what wallet/phone is =
=E2=80=8B=E2=80=8Bon<br>
&gt; the accepting side, so I have to be compatible to existing widely<br>
&gt; supported technologies.<br>
<br>
Agreed. All I wanted to say support for QR is still small enough that we<br=
>
might be able to switch to an incompatible standard. If we&#39;re determine=
d<br>
that is.</blockquote><div><div class=3D"gmail_default" style=3D"font-family=
:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">Ok. Btw, I&#39;ve teste=
d =E2=80=8BQR possibilities on my PoS screen, in binary mode it&#39;s limit=
ed to about 600 chars, so really I can include only unsigned and rather sho=
rt payment request. Signed requests longer than few hundred bytes will not =
work.</div>


</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; =E2=80=8BWell, yes, it would be less efficient than base43. But did yo=
u<br>
&gt; calculate how much less? =E2=80=8BIt&#39;s a compatible and already wi=
dely used way<br>
&gt; and loosing compatibility needs to have serious reasons, so would be<b=
r>
&gt; great to know exact figures here.<br>
<br>
Base 64 via binary QR: =C2=A0 64 chars / 256 chars<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0=3D=3D&gt; 6 bit / 8 bit =3D 0.75<br>
<br>
Base 43 via alphanum QR: 43 chars / 45 chars<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0=3D=3D&gt; 5.43 bit / 5.49 bit =3D 0.99<br>
<br>
That would be efficiency in terms of PR data size vs. amount space used<br>
in a QR code. Of course, the visual QR encoding also plays a role, for<br>
example its size is increased in discrete steps.<br></blockquote><div><div =
class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,monospac=
e;color:rgb(0,51,0)">Ok, so base43-aphanum is winning about a quarter of ca=
pacity against base64-binary. I probably will skip this anyway and go with =
bluetooth URI scheme we&#39;ve just agreed + old style payments over p2p ne=
twork as fallback. So no payment requests in QR codes at all from my side.<=
/div>

<br></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
Learn Graph Databases - Download FREE O&#39;Reilly Book<br>
&quot;Graph Databases&quot; is the definitive new guide to graph databases =
and their<br>
applications. Written by three acclaimed leaders in the field,<br>
this first edition is now available. Download your free book today!<br>
<a href=3D"http://p.sf.net/sfu/13534_NeoTech" target=3D"_blank">http://p.sf=
.net/sfu/13534_NeoTech</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>

--001a11334c38a430fd04f51e3be8--