On Wed, Sep 25, 2013 at 01:35:48PM +0200, Melvin Carvalho wrote:
> On 25 September 2013 13:15, Mike Hearn wrote:
>
> > It won't fit. But I don't see the logic. A URI contains instructions for
> > making a payment. If that instruction is "pay to this address" or "download
> > this file and do what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/25/2013 07:35 AM, Melvin Carvalho wrote:
> It depends on the attacker. I think a large entity such as a govt
> or big to medium size corporation *may* be able to MITM https, of
> course the incentive to do so is probably not there ...
DLP (dat
Low light shouldn't be an issue for QRcodes generated by phones. They have
backlit screens that should always be bright enough. I can see how it might
be an issue for printed codes.
If your phone has no Bitcoin app installed then being redirected to an
invoice page is pretty useless, you still won
BitPay experimented with QR codes in low light, restaurant and other
conditions. QR codes become difficult to use even at 100 chars.
On the merchant side, we prefer a short URL that speaks payment
protocol if visited via bitcoin client, but will gracefully work if
scanned by a phone with zero bit
On Wed, Sep 25, 2013 at 6:28 AM, Andreas Schildbach
wrote:
> As soon as there is a BIP70 implementation, I will begin playing with
> putting the payment request directly into the QR code.
You may test with Bitcoin-QT right now.
--
Jeff Garzik
Senior Software Engineer and open source evangelist
On 09/25/2013 01:45 PM, Mike Hearn wrote:
> OK, it might fit if you don't use any of the features the protocol
> provides :)
Now you're dver-dramaticing (-:
I'm just skipping one feature which I think is useless for QR codes
scanned in person.
> You can try it here:
Thanks. A typical request w
On Wed, Sep 25, 2013 at 1:33 PM, Andreas Schildbach
wrote:
> Why do you think that? Of course, I would skip the certificate, as its
> unnecessary if you see your partner in person.
>
OK, it might fit if you don't use any of the features the protocol provides
:) You can try it here:
https://bitco
On 25 September 2013 13:15, Mike Hearn wrote:
> It won't fit. But I don't see the logic. A URI contains instructions for
> making a payment. If that instruction is "pay to this address" or "download
> this file and do what you find there", it's no different unless there's
> potential for a MITM a
On 09/25/2013 01:15 PM, Mike Hearn wrote:
> It won't fit.
Why do you think that? Of course, I would skip the certificate, as its
unnecessary if you see your partner in person.
> But I don't see the logic. A URI contains instructions for
> making a payment. If that instruction is "pay to this add
It won't fit. But I don't see the logic. A URI contains instructions for
making a payment. If that instruction is "pay to this address" or "download
this file and do what you find there", it's no different unless there's
potential for a MITM attack. If the request URL is HTTPS or a secured
Bluetoot
While it's good to save space, I'm at the moment not convinced that
taking a de-route via an URL is a good idea to begin with.
The main problem is trust. If you scan a QR code from a foreign phone,
you trust that that phone is owned by the one you want to send money to.
By adding the HTTP request
We could also say that if protocol part (https://) is missing, it's implied
automatically. So just:
bitcoin:1abc?r=bob.com/r/aZgR
I think that's about as small as possible without re-using the pubkey as a
token in the url.
On Wed, Sep 25, 2013 at 1:35 AM, Gavin Andresen wrote:
> On Tue
12 matches
Mail list logo
