📅 Original date posted:2014-03-21
📝 Original message:2014-03-21 9:47 GMT+00:00 Andreas Schildbach <andreas at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140321/e73d4f4a/attachment.html>;
Alex Kotenko [ARCHIVE] /
npub14j…h00t4
2023-06-07 15:14:28
in reply to nevent1q…vd04
Author Public Key
npub14jv7tj33yt72yk8mljmvkck3p4xm5s3mxfpj289up38qqsn9dhkqeh00t4Published at
2023-06-07 15:14:28Event JSON
{
"id": "86690216557b6861c866f0ff17ffdd943b98fd18379f3d75e4dad5547edf3d0d",
"pubkey": "ac99e5ca3122fca258fbfcb6cb62d10d4dba423b3243251cbc0c4e0042656dec",
"created_at": 1686150868,
"kind": 1,
"tags": [
[
"e",
"d70d8d12a406cb1c9a067111bb9c717b35fd85b951e12f89e562fccc2fad4277",
"",
"root"
],
[
"e",
"1ac800d3aefbc19b81571734dce2079f365a16ef78141b52772664c3cfd420e3",
"",
"reply"
],
[
"p",
"3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc"
]
],
"content": "📅 Original date posted:2014-03-21\n📝 Original message:2014-03-21 9:47 GMT+00:00 Andreas Schildbach \u003candreas at schildbach.de\u003e:\n\n\u003e On 03/20/2014 05:14 PM, Alex Kotenko wrote:\n\u003e\n\u003e \u003e Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing\n\u003e \u003e URI's patterns. BT is strictly point-to-point connection, so BT MAC\n\u003e \u003e should be considered as server address, and payment request ID can be\n\u003e \u003e considered as request path. Probably \"bt:\u003cbt-mac\u003e/\n\u003e \u003e \u003crandom_id_of_payment_request\u003e\" would be more usual and easily\n\u003e \u003e understandable.\n\u003e\n\u003e Agreed. I used the dash because I feared a slash would need to be\n\u003e escaped if used in an URL parameter.\n\u003e\nIt will need to be escaped, but HTTP URLs used in BIP72 have it already,\nso don't see why we should bother.\n\n\n\n\u003e \u003e I wonder how complex it would be to implement HTTP-over-Bluetooth. Not\n\u003e \u003e like I'm willing to do that now, but HTTP is well known and proven to be\n\u003e \u003e quite good for tasks like this, so in theory it would be handy to have\n\u003e \u003e such capacities in here.\n\u003e\n\u003e Thought of that as well. On the other hand, HTTP might be overkill and\n\u003e we inherit its potential downsides as well.\n\u003e\nIt definitely is an overkill. Don't think we should do it now unless we\nwill see later during implementation that we really have to.\n\n\n\n\u003e \u003e Well, do we need to be compatible? If the dev community decides\n\u003e Base43\n\u003e \u003e PR QR's (or whatever other self-contained format) is the way to go,\n\u003e we\n\u003e \u003e just implement, roll it out and use it.\n\u003e \u003e\n\u003e \u003e My PoS needs to be compatible with BIP21, as when I'm presenting QR code\n\u003e \u003e or sending NFC message - I have no way to tell what wallet/phone is on\n\u003e \u003e the accepting side, so I have to be compatible to existing widely\n\u003e \u003e supported technologies.\n\u003e\n\u003e Agreed. All I wanted to say support for QR is still small enough that we\n\u003e might be able to switch to an incompatible standard. If we're determined\n\u003e that is.\n\nOk. Btw, I've tested QR possibilities on my PoS screen, in binary mode\nit's limited to about 600 chars, so really I can include only unsigned and\nrather short payment request. Signed requests longer than few hundred bytes\nwill not work.\n\n\n\n\u003e \u003e Well, yes, it would be less efficient than base43. But did you\n\u003e \u003e calculate how much less? It's a compatible and already widely used way\n\u003e \u003e and loosing compatibility needs to have serious reasons, so would be\n\u003e \u003e great to know exact figures here.\n\u003e\n\u003e Base 64 via binary QR: 64 chars / 256 chars\n\u003e ==\u003e 6 bit / 8 bit = 0.75\n\u003e\n\u003e Base 43 via alphanum QR: 43 chars / 45 chars\n\u003e ==\u003e 5.43 bit / 5.49 bit = 0.99\n\u003e\n\u003e That would be efficiency in terms of PR data size vs. amount space used\n\u003e in a QR code. Of course, the visual QR encoding also plays a role, for\n\u003e example its size is increased in discrete steps.\n\u003e\nOk, so base43-aphanum is winning about a quarter of capacity against\nbase64-binary. I probably will skip this anyway and go with bluetooth URI\nscheme we've just agreed + old style payments over p2p network as fallback.\nSo no payment requests in QR codes at all from my side.\n\n\n\n\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Learn Graph Databases - Download FREE O'Reilly Book\n\u003e \"Graph Databases\" is the definitive new guide to graph databases and their\n\u003e applications. Written by three acclaimed leaders in the field,\n\u003e this first edition is now available. Download your free book today!\n\u003e http://p.sf.net/sfu/13534_NeoTech\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140321/e73d4f4a/attachment.html\u003e",
"sig": "b3f5f168f4a0ae68b0bb5a0f7542fc1a7e95b55beb1b731d1e112f8154cb4d1639fcbd64ab77d625f6ee9095c2a967d493e2e4657750cf0ec821497e5705a0d9"
}