Paul Puey [ARCHIVE] on Nostr: 📅 Original date posted:2015-02-05 📝 Original message:Although consumer to ...
📅 Original date posted:2015-02-05
📝 Original message:Although consumer to merchant is a use case for BLE I would argue that NFC has a higher chance of providing a better user experience in most cases since, at least on Android, a user can tap their phone without even having a wallet running. The URI handler will launch the wallet for them. However a dedicated, user facing, screen can give certainty that the user is connecting to the correct recipient.
1. Because it can show an address prefix
2. It can display the users nickname/handle upon connecting which is only sent to the merchant upon a point to point connection. Not a broadcast.
The Airbitz wallet already does this on the recipient side. A popup shows the most recent person connecting to the recipient.
Paul Puey CEO / Co-Founder, Airbitz Inc
619.850.8624 | http://airbitz.co | San Diego
On Feb 5, 2015, at 3:34 PM, Roy Badami <roy at gnomon.org.uk> wrote:
For peer-to-peer payments, how common do we think that the payment is
of an ad hoc nature rather than to a known contact?
If I want to pay my friends/colleagues/etc over a restaurant table
there's no reason why I couldn't already have their public keys in my
contact list - then it would be pretty straightforward to have a
watertight mechanism where I would know who I was paying. You could
probably even relatively securely bootstrap a key exchange over SMS,
relying only on the contacts already having each other in their
phonebooks.
As for comsumer-to-merchant transactions where the merchant is a
bricks and mortar merchant, IMHO it absolutely has to be "pay that
terminal over there". It's the trust model we all currently use -
whether paying cash or card - and it's the only trust model that works
IMHO (and customers and businesses alike are well aware of the risks
of a fraudster standing behind the counter pretending to be an
employee accepting payment - and by and large are pretty good at
mitigating it). OTOH as we've discussed here before there are many
use cases where the custoemr doesn't actually know or care about the
name of the shop or bar they walked into but is pretty damn sure that
they need to make payment to the person over there behind the counter.
Granted, there are cases taht dont' fall into either of the above -
but they're the cases that are (a) harder to figure out how to
authenticate and consequently (b) the use cases that are going to be
most subject to attempted fraud.
roy
> On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote:
>> On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil <eric at voskuil.org> wrote:
>> A MITM can receive the initial broadcast and then spoof it by jamming the
>> original. You then only see one.
>
> You are right, of course. There is no way to make Bluetooth 100%
> secure, since it is an over-the-air technology. You could try securing
> it using a CA or other identity server, but now you've excluded ad-hoc
> person-to-person payments. Plus, you need an active internet
> connection to reach the CA.
>
> You can try using proximity as a substitute for identity, like
> requiring NFC to kick-start the connection, but at that point you
> might as well use QR codes.
>
> This BIP is not trying to provide absolute bullet-proof security,
> since that's impossible given the physical limitations of the
> Bluetooth technology. Instead, it's trying to provide the
> best-possible security given those constraints. In exchange for this,
> we get greatly enhanced usability in common scenarios.
>
> There are plenty of usable, real-world technologies with big security
> holes. Anybody with lock-picking experience will tell you this, but
> nobody is welding their front door shut. The ability to go in and out
> is worth the security risk.
>
> Bluetooth payments add a whole new dimension to real-world Bitcoin
> usability. Do we shut that down because it can't be made perfect, or
> do we do the best we can and move forward?
>
> -William
>
> ------------------------------------------------------------------------------
> 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/dece93e9/attachment.html>;
📝 Original message:Although consumer to merchant is a use case for BLE I would argue that NFC has a higher chance of providing a better user experience in most cases since, at least on Android, a user can tap their phone without even having a wallet running. The URI handler will launch the wallet for them. However a dedicated, user facing, screen can give certainty that the user is connecting to the correct recipient.
1. Because it can show an address prefix
2. It can display the users nickname/handle upon connecting which is only sent to the merchant upon a point to point connection. Not a broadcast.
The Airbitz wallet already does this on the recipient side. A popup shows the most recent person connecting to the recipient.
Paul Puey CEO / Co-Founder, Airbitz Inc
619.850.8624 | http://airbitz.co | San Diego
On Feb 5, 2015, at 3:34 PM, Roy Badami <roy at gnomon.org.uk> wrote:
For peer-to-peer payments, how common do we think that the payment is
of an ad hoc nature rather than to a known contact?
If I want to pay my friends/colleagues/etc over a restaurant table
there's no reason why I couldn't already have their public keys in my
contact list - then it would be pretty straightforward to have a
watertight mechanism where I would know who I was paying. You could
probably even relatively securely bootstrap a key exchange over SMS,
relying only on the contacts already having each other in their
phonebooks.
As for comsumer-to-merchant transactions where the merchant is a
bricks and mortar merchant, IMHO it absolutely has to be "pay that
terminal over there". It's the trust model we all currently use -
whether paying cash or card - and it's the only trust model that works
IMHO (and customers and businesses alike are well aware of the risks
of a fraudster standing behind the counter pretending to be an
employee accepting payment - and by and large are pretty good at
mitigating it). OTOH as we've discussed here before there are many
use cases where the custoemr doesn't actually know or care about the
name of the shop or bar they walked into but is pretty damn sure that
they need to make payment to the person over there behind the counter.
Granted, there are cases taht dont' fall into either of the above -
but they're the cases that are (a) harder to figure out how to
authenticate and consequently (b) the use cases that are going to be
most subject to attempted fraud.
roy
> On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote:
>> On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil <eric at voskuil.org> wrote:
>> A MITM can receive the initial broadcast and then spoof it by jamming the
>> original. You then only see one.
>
> You are right, of course. There is no way to make Bluetooth 100%
> secure, since it is an over-the-air technology. You could try securing
> it using a CA or other identity server, but now you've excluded ad-hoc
> person-to-person payments. Plus, you need an active internet
> connection to reach the CA.
>
> You can try using proximity as a substitute for identity, like
> requiring NFC to kick-start the connection, but at that point you
> might as well use QR codes.
>
> This BIP is not trying to provide absolute bullet-proof security,
> since that's impossible given the physical limitations of the
> Bluetooth technology. Instead, it's trying to provide the
> best-possible security given those constraints. In exchange for this,
> we get greatly enhanced usability in common scenarios.
>
> There are plenty of usable, real-world technologies with big security
> holes. Anybody with lock-picking experience will tell you this, but
> nobody is welding their front door shut. The ability to go in and out
> is worth the security risk.
>
> Bluetooth payments add a whole new dimension to real-world Bitcoin
> usability. Do we shut that down because it can't be made perfect, or
> do we do the best we can and move forward?
>
> -William
>
> ------------------------------------------------------------------------------
> 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/dece93e9/attachment.html>;