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

​It will need to be ​escaped, but HTTP URLs used in BIP72 have 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 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.

​It definitely is an overkill. Don't think we should do it now unless 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 code
> or sending NFC message - I have no way to tell what wallet/phone is on
> 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 ​QR 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.

> Well, yes, it would be less efficient than base43. But did you
> calculate how much less? It'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
==> 6 bit / 8 bit = 0.75

Base 43 via alphanum QR: 43 chars / 45 chars
==> 5.43 bit / 5.49 bit = 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 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-development