From: Roy Badami <roy@gnomon•org.uk>
To: Jeremy Spilman <jeremy@taplink•co>
Cc: bitcoin-development@lists•sourceforge.net,
Andreas Schildbach <andreas@schildbach•de>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Date: Mon, 27 Jan 2014 20:34:36 +0000 [thread overview]
Message-ID: <20140127203435.GU38964@giles.gnomon.org.uk> (raw)
In-Reply-To: <op.xacvcukvyldrnw@laptop-air>
On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote:
> On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach
> <andreas@schildbach•de> wrote:
>
> > SCAN TO PAY
> > For scan-to-pay, the current landscape looks different. I assume at
> > least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded
> > into a QR-code. Nevertheless, I tried to encode a payment request into
> > the bitcoin URL. I used my existing work on encoding transactions into
> > QR-codes. Steps to encode:
>
> Really interesting work. When using scan-to-pay, after the payer scans the
> QR code with the protobuf PaymentRequest (not a URL to download the
> PaymentRequest) are they using their own connectivity to submit the
> Payment response?
>
> If we assume connectivity on the phone, might as well just get a URL from
> the QR code and re-use existing infrastructure for serving that?
My first thought was likewise. In the case where the phone needs
Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL?
I'm assuming that every client will have to support this is any case,
since it's effectively mandated by the BIP, so why add another mode of
operation?
However, PaymentRequest-over-QR-code does seem to me to have one
rather attractive advantage: the authentication model is orders of
magnitude simpler and more intuitive for a face-to-face transaction
than anything else. You're saying "pay the coins to that thing over
there displaying that QR code". Which, most of the time, is exactly
what you want.
In the web case, it's fine to ignore the case where the URL domain has
been subverted (and an cert obtained by the attacker) because in that
case you've lost before you even get to payments (MitM attacker shows
you a modified web page with different payment details). But the
face-to-face case isn't intrinsically dependent on SSL security, and
it's nice not to introduce that attack vector...
roy
next prev parent reply other threads:[~2014-01-27 20:34 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-27 11:59 Andreas Schildbach
2014-01-27 13:11 ` Mike Hearn
2014-01-27 18:18 ` Andreas Schildbach
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 [this message]
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=20140127203435.GU38964@giles.gnomon.org.uk \
--to=roy@gnomon$(echo .)org.uk \
--cc=andreas@schildbach$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jeremy@taplink$(echo .)co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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