Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.128.172 as permitted sender)
	client-ip=209.85.128.172; envelope-from=alexy.kot.all@gmail.com;
	helo=mail-ve0-f172.google.com; 
MIME-Version: 1.0
Sender: alexy.kot.all@gmail.com
In-Reply-To: <lge7lv$3mf$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>
From: Alex Kotenko <alexykot@gmail.com>
Date: Thu, 20 Mar 2014 16:14:27 +0000
Message-ID: <CALDj+BZRsXnU5w=1B+01PDfMPY-7zqU3GP_52vr9wknEdTJ59Q@mail.gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=001a11c2c93299635604f50c127b
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Precedence: list

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

2014-03-20 8:08 GMT+00:00 Andreas Schildbach <andreas@schildbach.de>:

> On 03/20/2014 03:22 AM, Alex Kotenko wrote:
> > Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and =
I
> > need to still be able to use it for backwards compatibility. But at the
> > same time I want to be able to support BIP70. And also I want to avoid
> > using external servers, the concept of my POS is that everything is
> > happening between just payer's phone and payee's POS device. This means
> > that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.
>
> We could use Bluetooth in the "r" parameter, not unlike we use Bluetooth
> in the payment_url. However, since multiple devices could access your
> machine at the same time, we need some for of adressibility of different
> payment requests. Something like
> "bt:<btmac>-
> =E2=80=8B=E2=80=8B
> <random_id_of_payment_request>".

=E2=80=8BI guess this would be best option=E2=80=8B. I'm also worried about=
 potential QR
code capacity, since as I imagine we can encounter device that has your
Wallet installed and bluetooth enabled, but no NFC available, so we will
have to operate via onscreen QR codes + bluetooth.
Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing
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_reque=
st>"
would be more usual and easily understandable.
Really I don't think my PoS will now support multiple simultaneous
payments, but it's good to have this thing in place for the time I will
need it.
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 be quite
good for tasks like this, so in theory it would be handy to have such
capacities in here.



>  > You're also offering an option to include Base43 encoded PR body right
> > inside the Bitcoin URI, but in a way that is not backwards compatible
> > with BIP21.
>
> 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 code 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.


> I understand your intention behind base43 encoding and noncompatible URI
> > - you want to make most possible use of QR codes. But I wonder - did yo=
u
> > compare this base43 to base64 encoded request in a binary QR code
> > format? How much do we actually win in total bytes capacity at a price
> > of noncompatibility and increased complexity?
>
> Alphanumeric QR codes have an alphabet of 45 chars, of which I am using
> 43. I skipped Space and '%' because they're not allowed in URIs. When I
> invented the Base43 format back in 2011, wanted it to be URI compatible
> so we can use the Android intent dispatcher.
>
> If we let go of the URI requirement, we can use binary QR codes as well.
> This means users will always have to manually start their Bitcoin app
> first. (Also, there is an implementation issue with the ZXing scanner
> I'm using, it returns Strings rather than a byte array so it will choke
> on \0 characters.)
>


> > And also maybe we can extend BIP72 to include encoded payment request i=
n
> > the URL directly in a backwards compatible way?
>
> I took this into consideration. It would be space inefficient.
>
> The Base58-encoded address from BIP21 forces the QR code into binary
> mode. Still you can't encode the payment request extension (probably an
> URL parameter) as binary because it needs to stay compatible to the URI
> standard (RFC 3986). You could use one of the Base64 variants for the PR
> in this case, but still it would be inefficient.

=E2=80=8BWell, yes, it would be less efficient than base43. But did you cal=
culate
how much less? =E2=80=8BIt's a compatible and already widely used way and l=
oosing
compatibility needs to have serious reasons, so would be great to know
exact figures here.

I can find out base64 size, but I don't have a working base43
implementation (since the only existing is in Java, and I don't speak it).
Can you give me a sample uncompressed PR file of moderate size and a base43
encoded version of it? And I'll convert it into base64 and compare.



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

--001a11c2c93299635604f50c127b
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-20 8:08 GMT+00:00 Andreas Schildbach </span><=
span dir=3D"ltr" style=3D"font-family:arial;color:rgb(34,34,34)">&lt;<a hre=
f=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@schildbach.de<=
/a>&gt;</span><span style=3D"font-family:arial;color:rgb(34,34,34)">:</span=
><br>


</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote cla=
ss=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;padding-left:1ex=
"><div>


On 03/20/2014 03:22 AM, Alex Kotenko wrote:<br>
&gt; Right now, before BIP70, I&#39;m sending BIP21 URI via NFC or QR code,=
 and I<br>
&gt; need to still be able to use it for backwards compatibility. But at th=
e<br>
&gt; same time I want to be able to support BIP70. And also I want to avoid=
<br>
&gt; using external servers, the concept of my POS is that everything is<br=
>
&gt; happening between just payer&#39;s phone and payee&#39;s POS device. T=
his means<br>
&gt; that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me.<br>
<br>
</div>We could use Bluetooth in the &quot;r&quot; parameter, not unlike we =
use Bluetooth<br>
in the payment_url. However, since multiple devices could access your<br>
machine at the same time, we need some for of adressibility of different<br=
>
payment requests. Something like<br>
&quot;bt:&lt;btmac&gt;-<div class=3D"gmail_default" style=3D"font-family:&#=
39;courier new&#39;,monospace;color:rgb(0,51,0);display:inline">=E2=80=8B=
=E2=80=8B</div>&lt;random_id_of_payment_request&gt;&quot;.</blockquote><div=
><div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mo=
nospace;color:rgb(0,51,0)">


=E2=80=8BI guess this would be best option=E2=80=8B. I&#39;m also worried a=
bout potential QR code capacity, since as I imagine we can encounter device=
 that has your Wallet installed and bluetooth enabled, but no NFC available=
, so we will have to operate via onscreen QR codes + bluetooth.</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)">Hmm, if we&#39;re inventing an URI for bluetooth,=
 I&#39;d rather follow existing URI&#39;s patterns. BT is strictly point-to=
-point connection, so BT MAC should be considered as server address, and pa=
yment request ID can be considered as request path. Probably &quot;bt:&lt;b=
t-mac&gt;/=E2=80=8B&lt;random_id_of_payment_request&gt;&quot; would be more=
 usual and easily understandable.</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)">Really I don&#39;t think my PoS will now support =
multiple=C2=A0simultaneous payments, but it&#39;s good to have this thing i=
n place for the time I will need it.</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)">I wonder how complex it would be to implement HTT=
P-over-Bluetooth. Not like I&#39;m willing to do that now, but HTTP is well=
 known and proven to be quite good for tasks like this, so in theory it wou=
ld be handy to have such capacities in here.</div>


<div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,mon=
ospace;color:rgb(0,51,0)"><br></div></div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
>


<div>
&gt; You&#39;re also offering an option to include Base43 encoded PR body r=
ight<br>
&gt; inside the Bitcoin URI, but in a way that is not backwards compatible<=
br>
&gt; with BIP21.<br>
<br>
</div>Well, do we need to be compatible? If the dev community decides Base4=
3<br>
PR QR&#39;s (or whatever other self-contained format) is the way to go, we<=
br>
just implement, roll it out and use it.<br></blockquote><div class=3D"gmail=
_default" style=3D"font-family:&#39;courier new&#39;,monospace;color:rgb(0,=
51,0)">My PoS needs to be compatible with BIP21, as when I&#39;m presenting=
 QR code or sending NFC message - I have no way to tell what wallet/phone i=
s =E2=80=8B=E2=80=8Bon the accepting side, so I have to be compatible to ex=
isting widely supported technologies.</div>


<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div>
&gt; I understand your intention behind base43 encoding and noncompatible U=
RI<br>
&gt; - you want to make most possible use of QR codes. But I wonder - did y=
ou<br>
&gt; compare this base43 to base64 encoded request in a binary QR code<br>
&gt; format? How much do we actually win in total bytes capacity at a price=
<br>
&gt; of noncompatibility and increased complexity?<br>
<br>
</div>Alphanumeric QR codes have an alphabet of 45 chars, of which I am usi=
ng<br>
43. I skipped Space and &#39;%&#39; because they&#39;re not allowed in URIs=
. When I<br>
invented the Base43 format back in 2011, wanted it to be URI compatible<br>
so we can use the Android intent dispatcher.<br>
<br>
If we let go of the URI requirement, we can use binary QR codes as well.<br=
>
This means users will always have to manually start their Bitcoin app<br>
first. (Also, there is an implementation issue with the ZXing scanner<br>
I&#39;m using, it returns Strings rather than a byte array so it will choke=
<br>
on \0 characters.)<br></blockquote><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>&=
gt; And also maybe we can extend BIP72 to include encoded payment request i=
n<br>


&gt; the URL directly in a backwards compatible way?<br>
<br>
</div>I took this into consideration. It would be space inefficient.<br>
<br>
The Base58-encoded address from BIP21 forces the QR code into binary<br>
mode. Still you can&#39;t encode the payment request extension (probably an=
<br>
URL parameter) as binary because it needs to stay compatible to the URI<br>
standard (RFC 3986). You could use one of the Base64 variants for the PR<br=
>
in this case, but still it would be inefficient.</blockquote><div><div><div=
 class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39;,monospa=
ce;color:rgb(0,51,0)">=E2=80=8BWell, yes, it would be less efficient than b=
ase43. But did you calculate how much less? =E2=80=8BIt&#39;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.</div>

<div><div class=3D"gmail_default" style=3D"font-family:&#39;courier new&#39=
;,monospace;color:rgb(0,51,0)"><br></div><div class=3D"gmail_default" style=
=3D"font-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">I can fi=
nd out base64 size, but I don&#39;t have a working base43 implementation (s=
ince the only existing is in Java, and I don&#39;t speak it). Can you give =
me a sample uncompressed PR file of moderate size and a base43 encoded vers=
ion of it? And I&#39;ll convert it into base64 and compare. =C2=A0</div>

</div><div></div></div></div><div>=C2=A0</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(204,204,204);border-left-style:solid;=
padding-left:1ex">

<div>
---------------------------------------------------------------------------=
---<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>
</div><div><div>_______________________________________________<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>
</div></div></blockquote></div><br></div></div>

--001a11c2c93299635604f50c127b--