On 03/20/2014 03:22 AM, Alex Kotenko wrote:
Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
need to still be able to use it for backwards compatibility. But at the
same time I want to be able to support BIP70. And also I want to avoid
using external servers, the
Very, very limited. The more data you stuff in them, the less reliable and
slower scanning becomes. A URL is about the limit of what's practically
achievable. Even with that, BitPay have been complaining about the
increased character length from adding the https url to download the
payment request
2014-03-20 8:08 GMT+00:00 Andreas Schildbach andr...@schildbach.de:
On 03/20/2014 03:22 AM, Alex Kotenko wrote:
Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
need to still be able to use it for backwards compatibility. But at the
same time I want to be able to
On Thu, Mar 20, 2014 at 8:12 AM, Adam Back a...@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
2014-03-20 17:31 GMT+00:00 Jeff Garzik jgar...@bitpay.com:
On Thu, Mar 20, 2014 at 8:12 AM, Adam Back a...@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
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
Hmm, is there any other way to do it? Can we provide a signed payment
request and verify the sign on receiving side and this way protect from
bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't
a very well developed area, and my own skills are not enough to quickly
implement
With Java, in theory, you can use SSLSocketFactory.createSocket(btsocket,
address, 1234, true) to wrap a bluetooth socket in SSL. However I have not
tried it.
For now, just prototype and build your product without the security. We can
find someone to experiment with this, if you don't want to .
We'll see how it will go, maybe I will get to implement this somewhere soon.
Yes, I'm thinking exactly about radio MitM attacks possible with bluetooth.
I'll also look into using PKI inside the PoS for the merchant. It would be
great user experience if we would be able to provide a signed payment
On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote:
Yes, this overlaps somewhat with the PKI signing in BIP70, but not
entirely - you might want to serve unsigned payment requests, but
still have confidentiality and authenticity for a local face to face
transaction. The signing and
10 matches
Mail list logo
