📅 Original date posted:2014-03-20
📝 Original message:It really depends on the physical, real world size of the QR code.
If you have a big screen, and security permits displaying a larger QR
code, you can afford more bytes. If you are displaying a tiny postage
stamp 1-2cm in size, the practical byte limit is very low.
Ideally, you test your QR codes in real world conditions, before
picking the best path.
On Thu, Mar 20, 2014 at 1:42 PM, Alex Kotenko <alexykot at gmail.com> wrote:
> 2014-03-20 17:31 GMT+00:00 Jeff Garzik <jgarzik at bitpay.com>:
>>
>> On Thu, Mar 20, 2014 at 8:12 AM, Adam Back <adam at cypherspace.org> wrote:
>> > Whats a sensible limit on practical/convenient QR code size?
>>
>> Extremely limited. Preferably under 100 bytes. You will see
>> increasingly poor operating in varying light conditions, such as
>> paying via QR code on a printed receipt in a pub at night. That was
>> one of the motivations for BIP 73.
>
> Hmm, in this case I think base43 discussion is irrelevant. Even with best
> space utilization we can get we will not be able to fit in anything bigger
> than a smallest unsigned payment certificate. And that is not so useful. So
> probably we should stick with BIP73 approach and bluetooth URI scheme we're
> inventing.
>
>
>>
>>
>>
>> On Thu, Mar 20, 2014 at 4:09 AM, Andreas Schildbach
>> <andreas at schildbach.de> wrote:
>> > Afaik, BIP73 needs an external server (the web server).
>>
>> Yes. Internet connectivity is not a rarity these days. Near-field
>> web servers also work fine.
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc. https://bitpay.com/
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 15:14:20
in reply to nevent1q…j2wj
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 15:14:20Event JSON
{
"id": "1321cc661322997551d77a8f789b86a36ab4a288fbc46c6a68aa75a94fcc540b",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686150860,
"kind": 1,
"tags": [
[
"e",
"d70d8d12a406cb1c9a067111bb9c717b35fd85b951e12f89e562fccc2fad4277",
"",
"root"
],
[
"e",
"1912595f93e1ed29623644bc0a3dc1d26527d3337ca39b76ad56401e9fca665b",
"",
"reply"
],
[
"p",
"ac99e5ca3122fca258fbfcb6cb62d10d4dba423b3243251cbc0c4e0042656dec"
]
],
"content": "📅 Original date posted:2014-03-20\n📝 Original message:It really depends on the physical, real world size of the QR code.\n\nIf you have a big screen, and security permits displaying a larger QR\ncode, you can afford more bytes. If you are displaying a tiny postage\nstamp 1-2cm in size, the practical byte limit is very low.\n\nIdeally, you test your QR codes in real world conditions, before\npicking the best path.\n\n\n\nOn Thu, Mar 20, 2014 at 1:42 PM, Alex Kotenko \u003calexykot at gmail.com\u003e wrote:\n\u003e 2014-03-20 17:31 GMT+00:00 Jeff Garzik \u003cjgarzik at bitpay.com\u003e:\n\u003e\u003e\n\u003e\u003e On Thu, Mar 20, 2014 at 8:12 AM, Adam Back \u003cadam at cypherspace.org\u003e wrote:\n\u003e\u003e \u003e Whats a sensible limit on practical/convenient QR code size?\n\u003e\u003e\n\u003e\u003e Extremely limited. Preferably under 100 bytes. You will see\n\u003e\u003e increasingly poor operating in varying light conditions, such as\n\u003e\u003e paying via QR code on a printed receipt in a pub at night. That was\n\u003e\u003e one of the motivations for BIP 73.\n\u003e\n\u003e Hmm, in this case I think base43 discussion is irrelevant. Even with best\n\u003e space utilization we can get we will not be able to fit in anything bigger\n\u003e than a smallest unsigned payment certificate. And that is not so useful. So\n\u003e probably we should stick with BIP73 approach and bluetooth URI scheme we're\n\u003e inventing.\n\u003e\n\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Thu, Mar 20, 2014 at 4:09 AM, Andreas Schildbach\n\u003e\u003e \u003candreas at schildbach.de\u003e wrote:\n\u003e\u003e \u003e Afaik, BIP73 needs an external server (the web server).\n\u003e\u003e\n\u003e\u003e Yes. Internet connectivity is not a rarity these days. Near-field\n\u003e\u003e web servers also work fine.\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e Jeff Garzik\n\u003e\u003e Bitcoin core developer and open source evangelist\n\u003e\u003e BitPay, Inc. https://bitpay.com/\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Learn Graph Databases - Download FREE O'Reilly Book\n\u003e\u003e \"Graph Databases\" is the definitive new guide to graph databases and their\n\u003e\u003e applications. Written by three acclaimed leaders in the field,\n\u003e\u003e this first edition is now available. Download your free book today!\n\u003e\u003e http://p.sf.net/sfu/13534_NeoTech\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n\n\n\n-- \nJeff Garzik\nBitcoin core developer and open source evangelist\nBitPay, Inc. https://bitpay.com/",
"sig": "3c27e486199655d12064c0b70c5afeeeedab30168169ae975441d4bf82e4bf01341f19933eb6a604748cea4c87f9c1f327cc41728f2d13390977ac91494fc22f"
}