From mboxrd@z Thu Jan 1 00:00:00 1970 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"><<a href=3D"mailto:andreas@schildbach.de" target=3D"_blank">andrea= s@schildbach.de</a>></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> > Hmm, if we're inventing an URI for bluetooth, I'd rather follo= w existing<br> > URI's patterns. BT is strictly point-to-point connection, so BT MA= C<br> > should be considered as server address, and payment request ID can be<= br> > considered as request path. Probably "bt:<bt-mac>/=E2=80=8B= <br> > <random_id_of_payment_request>" would be more usual and eas= ily<br> > 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:'courier new',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'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"> > I wonder how complex it would be to implement HTTP-over-Bluetooth. Not= <br> > like I'm willing to do that now, but HTTP is well known and proven= to be<br> > quite good for tasks like this, so in theory it would be handy to have= <br> > 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:'courier new',monospace;col= or:rgb(0,51,0)">=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.</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"> > =C2=A0 =C2=A0 Well, do we need to be compatible? If the dev community = decides Base43<br> > =C2=A0 =C2=A0 PR QR's (or whatever other self-contained format) is= the way to go, we<br> > =C2=A0 =C2=A0 just implement, roll it out and use it.<br> ><br> > My PoS needs to be compatible with BIP21, as when I'm presenting Q= R code<br> > or sending NFC message - I have no way to tell what wallet/phone is = =E2=80=8B=E2=80=8Bon<br> > the accepting side, so I have to be compatible to existing widely<br> > 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're determine= d<br> that is.</blockquote><div><div class=3D"gmail_default" style=3D"font-family= :'courier new',monospace;color:rgb(0,51,0)">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.</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"> > =E2=80=8BWell, yes, it would be less efficient than base43. But did yo= u<br> > calculate how much less? =E2=80=8BIt's a compatible and already wi= dely used way<br> > and loosing compatibility needs to have serious reasons, so would be<b= r> > 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> 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> 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:'courier new',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'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'Reilly Book<br> "Graph Databases" 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--