On Wed, Sep 25, 2013 at 01:35:48PM +0200, Melvin Carvalho wrote:
On 25 September 2013 13:15, Mike Hearn m...@plan99.net 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
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
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
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
On Wed, Sep 25, 2013 at 6:28 AM, Andreas Schildbach
andr...@schildbach.de 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
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
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
-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 (data
On Tue, Sep 24, 2013 at 11:52 PM, Mike Hearn m...@plan99.net wrote:
BTW, on the make qrcodes more scannable front -- is it too late to
change BIP 72 so the new param is just r instead of request? Every byte
helps when it comes to qrcodes ...
Not too late, assuming there are no objections.
I think the confidence of the tx is not really the users concern anyway.
They wrote it so they know it's valid. If the merchant disagrees for some
reason then the user can find out, out of band when the goods/services are
not delivered.
On Tue, Aug 20, 2013 at 1:19 AM, Gavin Andresen
On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson andr...@petersson.atwrote:
I was just reviewing the integration work to integrate the Payment
Protocol into our products. Is there any notion of a standardized
invoice serialisation? If i pay for two Burgers and one Club Mate, how
would my
RE: making the bitcoin address in the bitcoin: URI optional:
Ok, I'm convinced, sometimes merchants won't want or need backwards
compatibility and sometimes it won't make sense for them to put an
arbitrary bitcoin: address there.
RE: should the customer's machine not broadcast the transaction:
I'd like to hear from other wallet implementors. Do you have a notion
of 'locked inputs' ? The tricky bit in constructing a transaction but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.
bitcoinj separates the concept of committing a
On 08/07/2013 05:10 PM, Gavin Andresen wrote:
I'd like to hear from other wallet implementors. Do you have a notion
of 'locked inputs' ? The tricky bit in constructing a transaction but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.
I
I see payment URIs rather as a replacement for bitcoin: URI rather
than an extension. It solves everything they did in a much cleaner
way, Given that bitcoin: have gotten some traction, we probably want
to reuse the moniker, but replace the rest entirely. In other words,
if a request is specified,
But the reality is that in many applications you need to provide a
single URL.
Consider existing point-of-sale systems that display QR codes for the
user to scan. They live within the limitations of existing bitcoin
URLs, but would no doubt benefit from the payments protocol.
It's not realistic
I've updated the BIP 72 spec at https://en.bitcoin.it/wiki/BIP_0072 so
the bitcoin address is optional:
If the request parameter is provided and backwards compatibility is
not required, then the bitcoin address portion of the URI may be
omitted (the URI will be of the form: bitcoin:?request=...
On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami r...@gnomon.org.uk wrote:
Is it envisaged to be possible/sensible to have a URI that is *only* a
payment request? i.e. something like the following (although I'm not
sure this is a valid URI):
On 31 July 2013 13:33, Gavin Andresen gavinandre...@gmail.com wrote:
On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami r...@gnomon.org.uk wrote:
Is it envisaged to be possible/sensible to have a URI that is *only* a
payment request? i.e. something like the following (although I'm not
sure
Since the payment request is available from a location defined in the URI,I think it would be appropriate to attach the PaymentACK once paymentaccepted by Merchant.This would make the request and receipt available for later review.Regards,Tamás BlummerFounder, CEOhttp://bitsofproof.com
I think it's important to expect PaymentRequest-only bitcoin URIs in the
future. Some types of payments (exotic transactions) may not make sense to
have a single fallback address. Or, a page with a bitcoin URI link may be
relying on a separate service provider to assemble the transaction.
On
On Thu, Aug 1, 2013 at 9:30 AM, E willbefull ewillbef...@gmail.com wrote:
I think it's important to expect PaymentRequest-only bitcoin URIs in the
future. Some types of payments (exotic transactions) may not make sense to
have a single fallback address.
P2SH addresses already support all
P2SH addresses support exotic transaction outputs, but not all exotic
transactions. This payment protocol can allow for combining multiple
outputs. A PaymentRequest for sending money to multiple parties, for
example, could not fall back to a single address.
On Wed, Jul 31, 2013 at 5:38 PM, Gavin
23 matches
Mail list logo
