From: Mike Hearn <mike@plan99•net>
To: Paul Puey <paul@airbitz•co>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
Date: Thu, 5 Feb 2015 21:28:37 +0100 [thread overview]
Message-ID: <CANEZrP3v=ySS4gragaWuBMWi_swocRRRq_kw2edo6+9kifgrFQ@mail.gmail.com> (raw)
In-Reply-To: <CABdy8DKS4arkkCLGC=66SUJm5Ugib1EWP7B6MkQRX1k-yd3WBw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4366 bytes --]
BIP70 requests can be sent over bluetooth as well, as can transactions.
Bitcoin Wallet can already send money even when offline by doing this. It's
transparent to the user. I mean original Bluetooth in this context - BLE
has incredibly tight data constraints and isn't really meant for data
transfer.
Yes Android Beam has a pretty stupid UI. You can actually tap the devices,
take them away and then press, but that's not obvious at all. There have
been new APIs added in recent releases that give more control over this, so
it's possible we can revisit things and make the UI better these days.
The donation to live performer example is good - there's no issue of
accidentally paying for someone else in this context as there's only one
recipient, but many senders.
The issue of confused payments remains in other situations though.
For the coffee shop use case, it'd be nicer (I think) if we aim for a
Square-style UI where the device broadcasts a (link to) a photo of the user
combined with a bluetooth MAC. Then the merchant tablet can show faces of
people in the shop, and can push a payment request to the users device.
That device can then buzz the user, show a confirmation screen, put
something on their smart watch etc or just auto-authorise the payment
because the BIP70 signature is from a trusted merchant. User never even
needs to touch their phone at all.
On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey <paul@airbitz•co> wrote:
> The BIP70 protocol would preclude individuals from utilizing the P2P
> transfer spec. It would also require that a Sender have internet
> connectivity to get the payment protocol info. BLE could enable payment w/o
> internet by first transferring the URI to from Recipient to Sender. Then in
> the future, we could sign a Tx and send it over BLE back to the recipient
> (who would still need internet to verify the Tx). This is an important use
> case for areas with poor 3G/4G connectivity as I've experience myself.
>
> Also, due to Android issues, NFC is incredibly clunky. The URI Sender is
> required to tap the screen *while* the two phones are in contact. We
> support NFC the same way Bitcoin Wallet does, but unless the payment
> recipient has a custom Android device (which a merchant might) then the
> usage model is worse than scanning a QR code. BLE also allows people to pay
> at a distance such as for a donation to a live performer. We'll look at
> adding this to the Motivation section.
>
> [image: logo]
> *Paul Puey* CEO / Co-Founder, Airbitz Inc
> +1-619-850-8624 | http://airbitz.co | San Diego
> <http://facebook.com/airbitz> <http://twitter.com/airbitz>
> <https://plus.google.com/118173667510609425617>
> <https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey>
> <https://angel.co/paul-puey>
> *DOWNLOAD THE AIRBITZ WALLET:*
> <https://play.google.com/store/apps/details?id=com.airbitz>
> <https://itunes.apple.com/us/app/airbitz/id843536046>
>
>
> From: Andreas Schildbach <andreas@sc•..> - 2015-02-05 13:47:04
>
> Thanks Paul, for writing up your protocol!
>
> First thoughts:
>
> For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
> publish BIP70 payment requests instead. URIs mainly stick around because
> of QR codes limited capacity. BIP70 would partly address the "copycat"
> problem by signing payment requests.
>
> In your Motivation section, I miss some words about NFC. NFC already
> addresses all of the usability issues mentioned and is supported by
> mobile wallets since 2011. That doesn't mean your method doesn't make
> sense in some situations, but I think it should be explained why to
> prefer broadcasting payment requests over picking them up via near field
> radio.
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 10306 bytes --]
next prev parent reply other threads:[~2015-02-05 20:28 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-05 20:06 Paul Puey
2015-02-05 20:28 ` Mike Hearn [this message]
2015-02-05 20:37 ` Paul Puey
2015-02-05 20:43 ` Mike Hearn
2015-02-05 20:44 ` Eric Voskuil
2015-02-05 20:50 ` Mike Hearn
2015-02-05 20:59 ` Eric Voskuil
2015-02-05 21:19 ` Brian Hoffman
2015-02-05 21:23 ` Eric Voskuil
2015-02-05 21:36 ` Mike Hearn
2015-02-05 21:46 ` Eric Voskuil
2015-02-05 22:07 ` Paul Puey
2015-02-05 22:10 ` Eric Voskuil
2015-02-05 22:49 ` Roy Badami
2015-02-05 23:22 ` MⒶrtin HⒶboⓋštiak
2015-02-05 23:02 ` William Swanson
2015-02-05 23:34 ` Roy Badami
2015-02-05 23:59 ` Eric Voskuil
2015-02-06 8:59 ` Roy Badami
2015-02-06 9:13 ` Eric Voskuil
2015-02-06 0:58 ` Paul Puey
2015-02-05 23:22 ` Eric Voskuil
2015-02-05 23:36 ` MⒶrtin HⒶboⓋštiak
2015-02-05 23:46 ` Eric Voskuil
2015-02-06 0:04 ` MⒶrtin HⒶboⓋštiak
2015-02-06 0:22 ` Eric Voskuil
2015-02-06 0:36 ` Martin Habovštiak
2015-02-06 1:29 ` Eric Voskuil
2015-02-06 9:07 ` MⒶrtin HⒶboⓋštiak
2015-02-10 16:55 ` Eric Voskuil
2015-02-10 17:16 ` MⒶrtin HⒶboⓋštiak
2015-02-10 17:56 ` Eric Voskuil
2015-02-06 0:49 ` Paul Puey
2015-02-06 0:50 ` Martin Habovštiak
2015-02-06 1:05 ` Eric Voskuil
2015-02-06 2:09 ` Paul Puey
2015-02-05 22:02 ` Paul Puey
2015-02-05 22:01 ` Paul Puey
2015-02-05 22:05 ` Eric Voskuil
2015-02-05 22:08 ` Paul Puey
-- strict thread matches above, loose matches on Subject: below --
2015-02-05 8:01 Paul Puey
2015-02-05 13:46 ` Andreas Schildbach
2015-02-05 13:57 ` 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='CANEZrP3v=ySS4gragaWuBMWi_swocRRRq_kw2edo6+9kifgrFQ@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=paul@airbitz$(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