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

On 03/20/2014 05:14 PM, Alex Kotenko wrote:<= br>
> Hmm, if we're inventing an URI for bluetooth, I'd rather follo= w existing
> URI's patterns. BT is strictly point-to-point connection, so BT MA= C
> should be considered as server address, and payment request ID can be<= br> > considered as request path. Probably "bt:<bt-mac>/=E2=80=8B=
> <random_id_of_payment_request>" would be more usual and eas= ily
> 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 i=
n BIP72 have it already, so don't see why we should bother.

=C2=A0

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

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 s=
hould do it now unless we will see later during implementation that we real=
ly have to.

=C2=A0

> =C2=A0 =C2=A0 Well, do we need to be compatible? If the dev community = decides Base43
> =C2=A0 =C2=A0 PR QR's (or whatever other self-contained format) is= the way to go, we
> =C2=A0 =C2=A0 just implement, roll it out and use it.
>
> My PoS needs to be compatible with BIP21, as when I'm presenting Q= R 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.

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 determine= d
that is.

Ok. Btw, I've teste= d =E2=80=8BQR possibilities on my PoS screen, in binary mode it'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.

=C2=A0

> =E2=80=8BWell, yes, it would be less efficient than base43. But did yo= u
> calculate how much less? =E2=80=8BIt's a compatible and already wi= dely used way
> and loosing compatibility needs to have serious reasons, so would be > great to know exact figures here.

Base 64 via binary QR: =C2=A0 64 chars / 256 chars
=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> 6 bit / 8 bit =3D 0.75

Base 43 via alphanum QR: 43 chars / 45 chars
=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> 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 ca=
pacity against base64-binary. I probably will skip this anyway and go with =
bluetooth URI scheme we'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>

=C2=A0

---------------------------------------------------------------------------= ---
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases = and their
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-de= velopment

--001a11334c38a430fd04f51e3be8--