public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andreas Schildbach <andreas@schildbach.de>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Date: Mon, 27 Jan 2014 19:18:11 +0100	[thread overview]
Message-ID: <lc67sl$h3$1@ger.gmane.org> (raw)
In-Reply-To: <CANEZrP3POX5SACS18_rrQxx=mzmthrM418zmd8Z7-5CBNFSW4Q@mail.gmail.com>

On 01/27/2014 02:11 PM, Mike Hearn wrote:

> I would like to see Bluetooth continue to work for scan-to-pay even in
> the signed case. So for this reason the current approach with a BTMAC
> parameter in the Bitcoin URI seems to work universally across NFC tags
> and QR codes, and would allow download of a signed PaymentRequest even
> in the case where a QR code is used.

I'm not saying I'm against signed payment requests, but unfortunately
they are just too big for QR-codes. Then again, QR-codes *can* take up
to 2 KB. How big would a very basic trust chain plus signature be?

> Because a Bitcoin URI already contains a public key (hash), re-using
> that to establish an encrypted/authd connection on top of an insecure
> RFCOMM socket would seem to be relatively straightforward.

I was under the impression that addresses will go away. Can you
elaborate on the mechanism?

>     Obviously such QR-encoded payment requests cannot grow in size as much
>     as using other media. In particular, I expect PKI signed requests are
>     out of question. However, in face to face payments the value of a sig
>     based on PKI is highly questionable, and the fact the sig cannot be
>     verified without TCP connectivity doesn't help.
> 
> Just a correction here - the reason signed payment requests are "large"
> (about 4000 bytes) is exactly because they *can* be verified offline,
> i.e. by a Trezor. The signed payment request contains all the data
> needed to establish its authenticity, including certificates and the
> signature itself. No TCP connection is needed.

Ok, that's good news (to me). However, you are going to manage trust
stores (adding and revoking) without TCP?

> For face to face payments, I think signing is still useful. For one, we
> want to keep the distinction between "merchant" and "user" as blurry and
> indistinct as possible. A strong separation between merchants and
> consumers is one of the many bad things about the credit card system.

Ack.

> Whilst initially we'd expect the payment protocol to be used by online
> webshops, in future it could be used by little corner shops, children's
> lemonade stands and so on.

Well I'm thinking the other way round. Use Bitcoin where its already
used today -- face to face.

> you probably still would like a receipt if you buy
> something from a local market trader.

Yes, but where is the problem?

> Another use case - we heard a story about a restaurant owner who
> accepted Bitcoin. He printed a static bitcoin URI onto a QR code on the
> menu. A month or two later he discovered one of his waiters had
> re-printed the menus with his own QR code! The people thought they had
> been paying for the meal, and in fact it went right into the pocket of
> the waiter.

Sad story, but it's really a special case. Using a printed QR-code is
clearly the wrong tool for his task, for several reasons.

And again, how is he going to provide the payment request to the payer
without TCP?

> As to how it works, well, that's not hard. Comodo give away free email
> address certs with a few mouse clicks, it's no harder than signing up
> for a website.

We don't want to force people to sign up anywhere. Bitcoin is instant-on.

>     - I chose to re-use the "bitcoin:" URL scheme
>
> Other wallets won't know what to do with it and would yield a strange
> error message.

Which is why I said we need some transition time.

> Rather than pack a file into a URL, if you don't want to
> use the current r= extension it's better for apps to just register to
> handle .bitcoinpaymentrequest files / the right MIME type. Downloading
> it and opening it would do the right thing automatically.

That's a good point. I'll implement this asap.

> Remember BIP 73 also! It says that with the apps built-in QR scanner, if
> you scan an HTTP[S] URI, you should try downloading it with a magic
> header. That way you can get a payment request file out of the server.
> Without the magic header (i.e.  a normal generic barcode scanner app) it
> would open a web page containing a bitcoin URI clickable link.

Interesting, did not know about this BIP. However I don't understand the
usecase. Its not like my browsers always display QR-codes with URL of
the page being shown. And if the page in question bothers to show a QR
code, it could just as well also link to a payment request resource (as
suggested above).





  reply	other threads:[~2014-01-27 18:18 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-27 11:59 [Bitcoin-development] Payment Protocol for Face-to-face Payments Andreas Schildbach
2014-01-27 13:11 ` Mike Hearn
2014-01-27 18:18   ` Andreas Schildbach [this message]
2014-01-27 18:34     ` Mike Hearn
2014-01-27 20:53     ` [Bitcoin-development] Experiment with linking payment requests via href Andreas Schildbach
2014-01-27 21:47       ` Mike Hearn
2014-01-27 17:11 ` [Bitcoin-development] Payment Protocol for Face-to-face Payments Jeremy Spilman
2014-01-27 17:39   ` Andreas Schildbach
2014-01-27 18:18     ` Jeremy Spilman
2014-01-27 20:34   ` Roy Badami
2014-01-29 14:57     ` Christophe Biocca
2014-01-30 10:46 ` Andreas Schildbach
2014-01-30 10:50   ` Mike Hearn
2014-02-07 23:15   ` Andreas Schildbach
2014-03-02  9:47 ` Andreas Schildbach
2014-03-02 11:50   ` Mike Hearn
2014-03-20  2:22     ` Alex Kotenko
2014-03-20  3:31       ` Jeff Garzik
2014-03-20  8:09         ` Andreas Schildbach
2014-03-20 10:36           ` Mike Hearn
2014-03-20 12:12             ` Adam Back
2014-03-20 12:20               ` Mike Hearn
2014-03-20 17:31               ` Jeff Garzik
2014-03-20 17:42                 ` Alex Kotenko
2014-03-20 18:01                   ` Jeff Garzik
2014-03-21 10:28                 ` Andreas Schildbach
2014-03-21 13:59                   ` Alex Kotenko
2014-03-22 16:35                     ` Jeff Garzik
2014-03-22 16:45                       ` Mike Hearn
2014-03-22 16:55                       ` Mark Friedenbach
2014-03-22 17:24                         ` Jeff Garzik
2014-03-22 17:30                           ` Mike Hearn
2014-03-23  3:47                             ` Alex Kotenko
2014-03-21 10:25               ` Andreas Schildbach
2014-03-21 10:59                 ` Adam Back
2014-03-21 11:08                   ` Mike Hearn
2014-03-21 11:33                     ` Mike Hearn
2014-03-21 12:25                       ` Adam Back
2014-03-21 13:07                         ` Mike Hearn
2014-03-20 18:20             ` Alex Kotenko
2014-03-20 18:31               ` Mike Hearn
2014-03-20 18:50                 ` Alex Kotenko
2014-03-20 21:52                 ` Roy Badami
2014-03-20 23:02                   ` Mike Hearn
2014-03-26 22:48                     ` Roy Badami
2014-03-26 22:56                       ` Mike Hearn
2014-03-26 23:20                         ` Andreas Schildbach
2014-03-27 10:08                           ` Mike Hearn
2014-03-27 13:31                             ` vv01f
2014-06-30 19:26                               ` Alex Kotenko
2014-07-01  8:18                                 ` Mike Hearn
2014-07-01  9:48                                   ` Andreas Schildbach
2014-07-01 10:42                                     ` Michael Wozniak
2014-07-01 13:03                                       ` Alex Kotenko
2014-07-01 14:59                                         ` Andreas Schildbach
2014-07-01 15:07                                           ` Michael Wozniak
2014-07-01 15:39                                             ` Andreas Schildbach
2014-07-01 17:18                                               ` Alex Kotenko
2014-07-01 17:59                                                 ` Mike Hearn
2014-07-02  8:49                                                   ` Alex Kotenko
2014-03-21 10:43                   ` Andreas Schildbach
2014-03-20  8:08       ` Andreas Schildbach
2014-03-20 16:14         ` Alex Kotenko
2014-03-21  9:47           ` Andreas Schildbach
2014-03-21 13:54             ` Alex Kotenko
2014-03-21 14:51               ` Andreas Schildbach
2014-03-21 15:38                 ` Alex Kotenko
2014-03-21 15:20               ` Andreas Schildbach
2014-03-21 15:24                 ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='lc67sl$h3$1@ger.gmane.org' \
    --to=andreas@schildbach.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox