What is Reddit's opinion of
Bitcoin Wallet - Airbitz?
From 3.5 billion Reddit comments
Popularity Score: 8
This app was mentioned in 16 comments, with an average of 2.25 upvotes
Best Comments
Airbitz just released their latest version (1.6.0) with improved handling of Transaction Malleability (although protocol changes to bitcoin core such as BIP62 are needed to fully resolve this issue)
https://play.google.com/store/apps/details?id=com.airbitz&hl=en
> ********* Privacy Notice *********
> The Airbitz application requests access to the device contact list, location, and personal information. This information is used on the device to provide an improved user experience in the following ways:
> 1. Autocomplete contacts from the user's address book after a transaction > 2. Autocomplete contacts from the user's address book to send Email or SMS payment requests > 3. Autocomplete business listings names after a transaction > 4. Geolocate user's device to find nearby businesses
> No personal info or contact list info ever leaves the device without first being encrypted by the user's credentials (username/password). Neither Airbitz nor any 3rd party has knowledge of the information accessed by the application.
I'm going to recommend AirBitz
It's a bitcoin wallet where you control the private keys and you can backup the wallet seed. Remember if you don't have the private keys, you dont own the bitcoin.
I'm on Android and have all the hot wallets After trying them out I've settled on Airbitz It's a powerful yet user friendly wallet for my daily bitcoin transactions The dev team are capable and it's regularly updated Check it out on Google Play: https://play.google.com/store/apps/details?id=com.airbitz
then it should do its job. Besides Mycelium there are two other interesting wallets:
I think Airbitz is pretty good.
Airbitz is what I used to find Ada's. Other restaurants that take Bitcoin in Seattle include:
- Seattle Wood Fired Pizza,
- Moondrop Coffee & Tea, and
- Fuel Sports Bar (which looks quite nice I must say)
- ... [ Airbitz Directory Screenshot showing these 3 ]
If you want to see the Airbitz Directory for Washington State you can find that here.
Get the app: Android, iOS. NOTE: The app doesn't require you sign in or even create an account in order to view the directory.
Paul Puey on Feb 05 2015 10:07:18PM:
So if you picked up the BLE broadcast request. All you know is that
someone within 100m is requesting bitcoin at a certain address. Not
necessarily who. The name is both optional, and possibly just a handle
of the user. If I'm sitting 5 ft away from someone at dinner and wanted to
pay them via BLE, I might see "Monkey Dude" on my list and simply ask him
"is that you?" If so, I send it. If there are two "Monkey Dude's" Then I
have to bother with the address prefix, but not otherwise.
[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>
DOWNLOAD THE AIRBITZ WALLET:
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <eric at voskuil.org> wrote:
> BLE has an advertised range of over 100m.
>
> http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
>
> In the case of mass surveillance that range could most likely be extended
> dramatically by the reviewer. I've seen WiFi ranges of over a mile with a
> strong (not FCC approved) receiver.
>
> WiFi hotspots don't have strong identity or a guaranteed position, so they
> can't be trusted for location.
>
> e
>
> On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike at plan99.net> wrote:
>
> This sounds horrible. You could basically monitor anyone with a wallet in
>> a highly populated area and track them super easily by doing facial
>> recognition.
>>
>
> We're talking about BLE, still? The radio tech that runs in the so called
> "junk bands" because propagation is so poor?
>
> My watch loses its connection to my phone if I just put it down and walk
> around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't
> going to be enabling mass surveillance any time soon. It barely goes
> through air, let alone walls.
>
> Anyway, whatever. I'm just bouncing around ideas for faster user
> interfaces. You could always switch it off or set it to be triggered by the
> presence of particular wifi hotspots, if you don't mind an initial bit of
> setup.
>
> Back on topic - the debate is interesting, but I think to get this to the
> stage of being a BIP we'd need at least another wallet to implement it?
> Then I guess a BIP would be useful regardless of the design issues. The
> prefix matching still feels flaky to me but it's hard to know if you could
> really swipe payments out of the air in practice, without actually trying
> it.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/b562bf05/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007338.html
Paul Puey on Feb 05 2015 10:02:54PM:
The implementation on Airbitz does not encourage or even let a user
broadcast a photo. Just an address prefix and "name/handle". And it's only
broadcast during the Receive request. Not generally while the app is
running although that's up to the implementation.
[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>
DOWNLOAD THE AIRBITZ WALLET:
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
On Thu, Feb 5, 2015 at 1:19 PM, Brian Hoffman <brianchoffman at gmail.com>
wrote:
> This sounds horrible. You could basically monitor anyone with a wallet in
> a highly populated area and track them super easily by doing facial
> recognition. Yes you could photograph people but it's way more burdensome.
> Sorry to go off topic a little.
>
>
> On Feb 5, 2015, at 3:50 PM, Mike Hearn <mike at plan99.net> wrote:
>
> I'm imagining myself walking around broadcasting my photo and MAC
>> address while hucksters push payment requests to me for approval
>
>
> I hate to break it to you, but you broadcast a photo of your face every
> time you walk outside ;)
>
> Bluetooth MAC addresses are random, they aren't useful identifiers. If
> someone can see you, a face is a far more uniquely identifying thing than a
> MAC.
>
> "Payment spam" might be a problem. I can imagine a wallet requiring that
> such requests are signed and then spammers can be blacklisted in the usual
> fashion so they can't push things to your phone anymore. Anyway, a hurdle
> that can be jumped if/when it becomes an issue.
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/0a99ec39/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007336.html
Andreas Schildbach on Feb 05 2015 01:46:44PM:
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.
On 02/05/2015 09:01 AM, Paul Puey wrote:
> Airbitz has developed and implemented a method for communicating a
> bitcoin URI across Bluetooth (BLE) or any other P2P, mid range,
> wireless, broadcast medium. The currently documented implementation is
> available in our iOS and Android mobile wallet (updated Android version
> with BLE coming in about 1 week). We would like to have the BIP pulled
> into Github for review and discussion. Here is the current BIP:
>
>
> BIP: TBD
>
> Title: P2P Wireless URI transfer
>
> Authors: Thomas Baker <tom’at’airbitz.co <http://airbitz.co>>, Paul Puey
> <paul’at’airbitz.co <http://airbitz.co>>
>
> Contributors: Joey Krug <joeykrug’at’gmail.com <http://gmail.com>>
>
> Status: proposal
>
> Type: Standards Track
>
> Created: 2015-01-12
>
>
> Table of Contents
>
> *
>
> Abstract
>
> *
>
> Motivation
>
> *
>
> Specification
>
> *
>
> Compatibility
>
> *
>
> Examples
>
> *
>
> References
>
>
> Abstract
>
> This is a protocol for peer-to-peer wireless transfer of a URI request
> using an open broadcast or advertisement channel such as Bluetooth,
> Bluetooth Low Energy, or WiFi Direct.
>
>
> Motivation
>
> There are disadvantages for a merchant (requester) and customer (sender)
> to exchange a URI request using QR codes that can be eliminated by using
> wireless broadcast or advertisements.
>
> Current QR code scan method to transfer a request URI from merchant
> (Requester) to customer (Sender) is cumbersome. A usual scenario is a
> merchant with a POS terminal for order entry and a separate tablet for
> transacting payments with bitcoin, and a customer with a smartphone.
> After the order is entered, the merchant enters payment request
> information into the tablet, generates the QR code representing the URI,
> and presents this to the customer. The customer prepares to scan the QR
> code with their smartphone by maneuvering the camera to the tablet. The
> tablet screen must be relatively clean, point at the customer, and held
> steady. The smartphone camera lens must be clean, point at the tablet
> screen, come into range, and held steady to focus and wait for a QR
> scan. Environmental conditions such as bright outdoor sunlight, indoor
> spot lights, or significant distance between QR code and camera can
> create difficult and cumbersome experiences for users.
>
> Using a wireless local broadcast allows the merchant to just enter the
> payment and wait. The tablet and smartphone are not maneuvered to align
> in any way. The customer observes broadcast listings, selects the
> appropriate one from possible simultaneous broadcasts from other POS
> stations nearby, examines the URI request details such as amount, and
> decides whether to send funds, initiating a bitcoin network transfer.
> The merchant and customer then receive the transaction confirmations and
> are done with the sale. Merchant and customer devices are kept private
> and secured in their own possession.
>
> The URI and other broadcast identification (Joe’s Grill #1) only contain
> public information. However, a copycat broadcaster acting as MITM might
> duplicate the broadcast simultaneously as the merchant, attempting to
> lure the customer to send funds to the copycat. That attack is mitigated
> with this broadcast method because of the partial address in the broadcast.
>
>
> Specification
>
> Requester generates a bitcoin URI request of variable length, and a
> limited descriptive identifier string. Requester then broadcasts the
> URI’s partial public address (<paddress>) plus identifier (<id>) over a
> publicly visible wireless channel.
>
> Sender scans for broadcasts on their device, examines and selects the
> desired request by the identifier and partial address. This connects a
> data channel to Requester.
>
> Requester sends full URI back over the data channel.
>
> Sender device ensures <paddress> is part of the full URI public address
> and checks the full address integrity. Checking the broadcast and full
> URI integrity prevents a copycat device within range from copying the
> partial address and fooling the customer into sending funds to the
> copycat instead.
>
> Below is a description of the protocol through Bluetooth Smart (Low Energy).
>
> Requestor Sender - Bitcoin transaction roles
>
> Peripheral Central - Bluetooth GAP definitions
>
> Mode Mode
>
> 1 |------------->| - Requestor Advertises partial bitcoin: URI +
> Name
>
> | ... |
>
> 2 |<-------------| - Subscribe then send sender's Name,
> requesting a response
>
> 3 |------------->| - ACK
>
> 4 |<-------------| - request Read Characteristic from peripheral
>
> 5 |------------->| - Sender receives full bitcoin: URI
>
>
> 1.
>
> Peripheral advertises over a service UUID a BLE extended
> advertisement with a Scan Response containing the partial address of
> a bitcoin URI and a Name, any plain text. The entire response is
> limited to 26 characters. The first 10 make up the first 10
> characters of the bitcoin URI public address where to send bitcoin,
> and must be present. The remaining characters are any plain text
> such as “The Habit 1” or “Starbucks-Reg 1”, more human readable
> information. The partial address serves as a check against a nearby
> attacker who may try to lure a Sender into sending payment to a
> separate wallet by advertising a similar Scan Response but cannot
> replicate a public address with the same leading 10 characters and
> different trailing characters.
>
> 2.
>
> When the Central scans the advertisement, it may display the Scan
> Response in a human readable listing using the two pieces of
> information. If Central chooses this advertisement to receive the
> full request, it then subscribes to the service and writes the
> characteristic (a second UUID) with it’s own name, or a blank if not
> sending a name, to the Peripheral.
>
> 3.
>
> Peripheral gets a characteristic write request of the Central’s
> name, and acknowledges the receipt by sending a server response.
>
> 4.
>
> Central receives a characteristic write (from the response) and
> immediately requests the entire bitcoin URI by issuing a read
> request on that characteristic.
>
> 5.
>
> Peripheral receives the read request and sends the entire bitcoin
> URI over that characteristic up to 512 bytes.
>
> This ends the proposed specification as the bitcoin URI transfer is
> complete. The Sender would then normally confirm the request and decide
> whether to initiate the fund transfer.
>
>
> Compatibility
>
> There are no prior BIPs covering this.
>
>
> Examples
>
> Airbitz iOS Bluetooth Low Energy to Bluetooth Low Energy request transfer.
>
>
> References
>
>
>
>
>
> logo
> Paul Puey CEO / Co-Founder, Airbitz Inc
> +1-619-850-8624 | http://airbitz.co <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>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007322.html
Paul Puey on Feb 05 2015 08:06:47PM:
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>
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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/77152aa7/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007324.html
Paul Puey on Feb 05 2015 10:01:06PM:
The broadcast is ONLY done when the wallet is in Receive mode. Same as when
the QR code is visible. The use of the Name section is specifically so
that a recipient can broadcast their name/handle. Not so the recipient
would broadcast the name of the Sender.
[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>
DOWNLOAD THE AIRBITZ WALLET:
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
On Thu, Feb 5, 2015 at 12:50 PM, Mike Hearn <mike at plan99.net> wrote:
> I'm imagining myself walking around broadcasting my photo and MAC
>> address while hucksters push payment requests to me for approval
>
>
> I hate to break it to you, but you broadcast a photo of your face every
> time you walk outside ;)
>
> Bluetooth MAC addresses are random, they aren't useful identifiers. If
> someone can see you, a face is a far more uniquely identifying thing than a
> MAC.
>
> "Payment spam" might be a problem. I can imagine a wallet requiring that
> such requests are signed and then spammers can be blacklisted in the usual
> fashion so they can't push things to your phone anymore. Anyway, a hurdle
> that can be jumped if/when it becomes an issue.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/8f1e83dc/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007335.html
Paul Puey on Feb 05 2015 10:08:28PM:
Although not perfect, and it may require visual/verbal verification, I
don't see what the trust issue is.
[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>
DOWNLOAD THE AIRBITZ WALLET:
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
On Thu, Feb 5, 2015 at 2:05 PM, Eric Voskuil <eric at voskuil.org> wrote:
> Hi Paul,
>
> The issue is in the establishment of trust. Anyone can broadcast the
> initial information.
>
> e
>
> On Feb 5, 2015, at 2:01 PM, Paul Puey <paul at airbitz.co> wrote:
>
> The broadcast is ONLY done when the wallet is in Receive mode. Same as
> when the QR code is visible. The use of the Name section is specifically
> so that a recipient can broadcast their name/handle. Not so the recipient
> would broadcast the name of the Sender.
>
> On Thu, Feb 5, 2015 at 12:50 PM, Mike Hearn <mike at plan99.net> wrote:
>
>> I'm imagining myself walking around broadcasting my photo and MAC
>>> address while hucksters push payment requests to me for approval
>>
>>
>> I hate to break it to you, but you broadcast a photo of your face every
>> time you walk outside ;)
>>
>> Bluetooth MAC addresses are random, they aren't useful identifiers. If
>> someone can see you, a face is a far more uniquely identifying thing than a
>> MAC.
>>
>> "Payment spam" might be a problem. I can imagine a wallet requiring that
>> such requests are signed and then spammers can be blacklisted in the usual
>> fashion so they can't push things to your phone anymore. Anyway, a hurdle
>> that can be jumped if/when it becomes an issue.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/1d6f9332/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007339.html
Mike Hearn on Feb 05 2015 08:28:37PM:
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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/806f0139/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007325.html
Paul Puey on Feb 05 2015 08:37:14PM:
Thanks for CC'ing me Mike. Having trouble receiving maillist list posts.
Even if a user could get the BIP70 URL in the URI, they would still need
internet to access the URL. This BLE spec doesn't preclude BIP70, but can
work with it while still allowing individuals without a certificate to
broadcast a request.
The issue of confused payments becomes less so if the Recipient broadcasts
a name along with the 10 digit public addr prefix. Only if there is a name
conflict will the user have to be concerned with the prefix. The name can
be something like
Mikes Coffee #1 and it can have a "Register #1" at the counter. A customer
facing screen can also show the 10 digit prefix.
[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>
DOWNLOAD THE AIRBITZ WALLET:
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
On Thu, Feb 5, 2015 at 12:28 PM, Mike Hearn <mike at plan99.net> wrote:
> 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 at 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 at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/52c1b824/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007326.html