On 02/05/2015 12:28 PM, Mike Hearn wrote: > 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.
I'm not sure you could assume this, even if the payer only received one broadcast. And if the payer receives multiple, it constitutes a DOS on the scenario, potentially unintentional. > The issue of confused payments remains in other situations though. Agree, the problem of the payer strongly identifying the receiver requires either proximity (NFC or QR code scan from the known-good source) or PKI/WoT. The problem can't be resolved through a broadcast. > 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. I'm imagining myself walking around broadcasting my photo and MAC address while hucksters push payment requests to me for approval, while recording my photo and correlating it to my address. It will pretty quickly turn in to a scenario where I need to touch something before this is turned on. > On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey <p...@airbitz.co > <mailto:p...@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. > > 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.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
