Martin,
I like your idea for the commit protocol in that it resolves the
vandalous address substitution attack. However, I don't see a way to
prevent privacy loss without adverse impact to the scenario.
Anyone could perform the handshake and thereby obtain the payment
request. Therefore to
On 02/10/2015 09:16 AM, MⒶrtin HⒶboⓋštiak wrote:
I'm not sure if I was clear enough. Handshake should be used to
establish authenticated AND encrypted communication using ECDH (or
just DH, but I think it's easier to use ECDH, since required functions
are already used in Bitcoin protocol), like
I'm not sure if I was clear enough. Handshake should be used to
establish authenticated AND encrypted communication using ECDH (or
just DH, but I think it's easier to use ECDH, since required functions
are already used in Bitcoin protocol), like RedPhone does. BTW
knowledge of verification string
In this case there is no need for P2P communication, just pay to an
address you already have for the other party. If you want to avoid
address reuse, use stealth addressing.
But yes, if you don't have a stealth address for the other party you can
certainly communicate in private as peers
2015-02-06 2:29 GMT+01:00 Eric Voskuil e...@voskuil.org:
On 02/05/2015 04:36 PM, Martin Habovštiak wrote:
I believe, we are still talking about transactions of physical
people in physical world. So yes, it's proximity based - people
tell the words by mouth. :)
Notice from my original
On 02/06/2015 12:59 AM, Roy Badami wrote:
In this case there is no need for P2P communication, just pay to an
address you already have for the other party. If you want to avoid
address reuse, use stealth addressing.
But yes, if you don't have a stealth address for the other party you can
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
For a BIP standard, I think we should skip bitcoin: URIs entirely and
publish BIP70 payment requests instead.
Agreed - it's not clear to me at all that this partial address scheme is
actually secure. The assumption appears to be that the MITM must match the
address prefix generated by the
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
Yes, a stellar device for mass surveillance coupled with transaction tainting.
e
On Feb 5, 2015, at 1:19 PM, Brian Hoffman brianchoff...@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
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
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
On 02/05/2015 12:50 PM, Mike Hearn 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
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
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 p...@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*
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
A MITM can receive the initial broadcast and then spoof it by jamming the
original. You then only see one.
e
On Feb 5, 2015, at 2:07 PM, Paul Puey p...@airbitz.co wrote:
So if you picked up the BLE broadcast request. All you know is that *someone*
within 100m is requesting bitcoin at a
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 /
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 /
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
Personally I like the simplicity of tapping two phones together to
make payment - it should be quicker and easier than scanning QR codes
and it's a trust model that's hard to misunderstand.
Is NFC good enough for that? I fear even with NFC it is possible to
produce a device with longer range
On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil e...@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
On 02/05/2015 02:08 PM, Paul Puey wrote:
Although not perfect, and it may require visual/verbal verification,
I don't see what the trust issue is.
I agree that with manual verification between the parties the worst
problem becomes DOS, which is certainly not catastrophic.
But the objective is
I would like to shortly express my opinion:
- Having BT as an alternative is good idea but it must be secure enough
- Signed BIP70 should be enough. I see only two issues regarding BIP70
(but they apply also to TCP/IP, not just BT): key revocations and MITM
attacks by governments.
- Broadcasting
A BIP-70 signed payment request in the initial broadcast can resolve the
integrity issues, but because of the public nature of the broadcast
coupled with strong public identity, the privacy compromise is much
worse. Now transactions are cryptographically tainted.
This is also the problem
On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote:
A BIP-70 signed payment request in the initial broadcast can resolve the
integrity issues, but because of the public nature of the broadcast
coupled with strong public identity, the privacy compromise is much
worse. Now transactions are
On 02/05/2015 03:34 PM, Roy Badami 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
On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote:
That's exactly what I though when seeing the RedPhone code, but after
I studied the commit protocol I realized it's actually secure and
convenient way to do it. You should do that too. :)
I was analyzing the model as you described it to me. A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I believe, we are still talking about transactions of physical people in
physical world. So yes, it's proximity based - people tell the words by mouth.
:)
In case of RedPhone, you read those words verbally over not-yet-verified
channel relying
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Commit protocol provides both better user experience and better security.
Dňa 6. februára 2015 1:49:12 CET používateľ Paul Puey p...@airbitz.co napísal:
The trust can be considered bootstrapped by visual verification of the
address prefix. If we
On 02/05/2015 04:49 PM, Paul Puey wrote:
The trust can be considered bootstrapped by visual verification of the
address prefix.
Another (unspendable) address can trivially match the prefix. Imagine
someone walking around in a mall with a phone in the pocket with a
malicious app, just disrupting
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.
The trust can be considered bootstrapped by visual verification of the address
prefix. If we are really concerned about someone jamming a Bluetooth signal in
a coffeeshop then the UI can encourage verification of the prefix. Much like
how regular Bluetooth requires 'pairing' via entering a 4-6
On 02/05/2015 04:36 PM, Martin Habovštiak wrote:
I believe, we are still talking about transactions of physical
people in physical world. So yes, it's proximity based - people
tell the words by mouth. :)
Notice from my original comment:
A MITM can substitute the key. If you don't have
Thanks for all the feedback Eric. You know we value all that you have to say.
That's what this forum is for. We're looking for great ideas to harden this
protocol and we're not closed to better ideas and we'll improve it as
suggestions come up.
Paul Puey CEO / Co-Founder, Airbitz Inc
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,
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
Even if a user could get the BIP70 URL in the URI, they would still need
internet to access the URL.
The way Bitcoin Wallet does it, the bitcoin URI includes a MAC address
where you can download the request from. BIP70 does not depend on internet
access or HTTP, plus, you don't have to sign
39 matches
Mail list logo
