On Friday, February 06, 2015 3:16:13 AM Justus Ranvier wrote:
On 02/04/2015 02:23 PM, Isidor Zeuner wrote:
Hi there,
traditionally, the Bitcoin client strives to hide which output
addresses are change addresses going back to the payer. However,
especially with today's dynamically
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
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
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
All this talk about URI's, bluetooth, P2P wireless transmissions, etc...
Ultimately, it is about a better user interface. Guys, I've already made
Bitcoin invoicing and payments exceptionally easy with Nakapay. Now if only
there's a wallet developer out there who would integrate it ...
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
Hello,
With the recent discussion started today regarding another bluetooth
communication proposal created by Airbitz, I'd like to bring people's
attention back to this proposal that saw little discussion last fall. I
guess I'm not sure why two proposals are being created. Is their some
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
Hi Andy,
This is good stuff. I've spent quite a bit of time on this question, but
set aside most of it earlier in the year in order to make some progress
in other areas. I did review what I found available at the time
pertaining to the Schildbach implementation and these questions.
Skimming the
-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
On Wed, Feb 04, 2015 at 03:23:23PM +0100, Isidor Zeuner wrote:
Hi there,
traditionally, the Bitcoin client strives to hide which output
addresses are change addresses going back to the payer. However,
especially with today's dynamically calculated miner fees, this
may often be ineffective:
On Wed, Feb 04, 2015 at 02:54:43PM +0100, Isidor Zeuner wrote:
Hi there,
comments in-line:
I later wrote up the idea in the context of adding Zerocoin to
Bitcoin:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
For the sake of maximum clarity
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
FYI, I've just tagged v0.10rc4, and pushed my signatures to the
gitian.sigs repository.
Please start your gitian builders!
Changes relative to rc3:
- 1eb14af Increase block download timeout base from 10 to 20 minutes.
- 3916a81 Increase coverage of DERSIG edge cases
- 6da2028 Add RPC test for
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
Agree, range is not an issue. The trade-off is in battery vs. total
time, which would be influenced primarily by the battery sensitivity of
the platform. I'll send you a note to follow up.
e
On 02/05/2015 05:40 PM, Andy Schroder wrote:
Hello,
I personally would prefer as low of range as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/04/2015 02:23 PM, Isidor Zeuner wrote:
Hi there,
traditionally, the Bitcoin client strives to hide which output
addresses are change addresses going back to the payer. However,
especially with today's dynamically calculated miner fees,
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
43 matches
Mail list logo
