[Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

Martin Habovštiak martin.habovstiak at gmail.com
Fri Feb 6 00:50:57 UTC 2015

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 <paul at airbitz.co> napísal:
>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 digit code.
>Paul Puey CEO / Co-Founder, Airbitz Inc
>619.850.8624 | http://airbitz.co | San Diego
>On Feb 5, 2015, at 3:46 PM, Eric Voskuil <eric at voskuil.org> wrote:
>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
>>> 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 with BIP-70 over the web. TLS and other
>>> security precautions aside, an interloper on the communication,
>>> datacenter, etc., can capture payment requests and strongly
>>> transactions to identities in an automated manner. The payment
>>> must be kept private between the parties, and that's hard to do.
>> What about using encryption with forward secrecy? Merchant would
>> generate signed request containing public ECDH part, buyer would send
>> back transaction encrypted with ECDH and his public ECDH part. If
>> receiving address/amount is meant to be private, use commit protocol
>> (see ZRTP/RedPhone) and short authentication phrase (which is hard to
>> spoof thanks to commit protocol - see RedPhone)?
>Hi Martin,
>The problem is that you need to verify the ownership of the public key.
>A MITM can substitute the key. If you don't have verifiable identity
>associated with the public key (PKI/WoT), you need a shared secret
>as a secret phrase). But the problem is then establishing that secret
>over a public channel.
>You can bootstrap a private session over the untrusted network using a
>trusted public key (PKI/WoT). But the presumption is that you are
>already doing this over the web (using TLS). That process is subject to
>attack at the CA. WoT is not subject to a CA attack, because it's
>decentralized. But it's also not sufficiently deployed for some

- --
Odoslané z môjho Android zariadenia pomocou K-9 Mail.
Version: APG v1.1.1


More information about the bitcoin-dev mailing list