Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Peter D. Gray]

I think the Bitcoin community needs a good person-to-person payment
protocol for BLE simply because Bluetooth LE is effectively
peer-to-peer. Unlike NFC or conventional Bluetooth, a $5 micro can
be either the master or slave and talk directly to other $5 micros
nearby.

[ASIDE...  BLE is also the first wireless tech that Apple has allowed us free
access to. They have claimed all NFC/RFID connections for their own
"Pay" junk, and Bluetooth accessories are all locked down into their
"make for iphone" program which literally requires a letter from
your lawyer to enter. Of course Apple is just one vendor.]

Surely, as a community, we can make a rock-solid P2P protocol that
is resistant to spoofing and vandalism. I'm a big fan of putting
crypto to good use, and doing a slightly more complex protocol
involving EC signing of nonces sounds great.

My only change to the RedPhone based "commit protocol" proposed
previously, is I'd like the confirmation code to be a 6-digit decimal
number rather than words. Wordlists are good for Red phone's audio
application, but it's a lot easier to display a 6-digit code on
vending machines, small mobile screens, and printed receipts.

Just my two cents.

---
Peter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG: A3A31BAD 
5A2A5B10



pgpaNC0CJGzTx.pgp
Description: PGP 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

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Mike Hearn]

>
> verification using breadwallet on apple is much faster (<1s) than HTTPS
> payment request on bitcoin wallet on android (apparently apple has a
> significantly more optimized signature verification algorithm).


Probably on Android it's being verified in Java instead of C++. Some
Android APIs are backed by OpenSSL but I don't know off hand if the way
we're verifying cert chains on Android is. It's eminently fixable, at any
rate.

X.509 cert chains are pretty bloated, but even so, shouldn't take several
seconds to transfer even over Bluetooth.

Bottom line is that there may be ~1s time transferring the data with this
> current bluetooth connection. Not sure how slow it will be with the BLE
> connection.
>

BLE isn't really connection oriented, as far as I know.
--
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

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Mike Hearn]

BLE meets a different use case than regular Bluetooth. BLE is designed to
allow always-on broadcast "beacons" which are conceptually similar to NFC
tags, with very low power requirements. The tradeoff for this ultra-low
power consumption and always on nature is the same as with NFC tags: you
get very little space for data, and they are essentially one way. That's
why a common use case for it is to trigger some other mechanism like a
classical Bluetooth socket or HTTPS connection.

I think BLE has a role to play in Bitcoin payments, but probably not for
actually transferring payment data. Rather, a merchant should be able to
drop a BLE beacon in their shop, and then wallet apps can use that to learn
where to download a payment request/upload a payment message. But the
actual data transfer would still take place over Bluetooth, Wifi or the
internet.

That leads to the question of what the beacon broadcasts. A bitcoin URI is
the obvious answer: the problem is a URI contains an address. No problem
for the "throw money at a live performer" use case but a problem for the
cafe use case. If we are willing to mandate BIP70 and remove the static
address part from the URI the we get a "uri that points to a url" which is
a bit inefficient but at least lets us distinguish bitcoin beacons from
other kinds. That still leaves the fundamental question raised by the
Airbitz spec - how does your wallet download the right payment request?

Unfortunately that's a tough UI problem. I don't think comparing long hex
strings manually is a good way to go. This seems less user friendly than a
QR code.

Once we solve that problem, how BLE beacons can trigger payments will all
fall into place. The tech part isn't the hard part.
--
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

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Eric Voskuil]

On 02/06/2015 12:40 AM, Andreas Schildbach wrote:
> On 02/06/2015 01:36 AM, Eric Voskuil wrote:
> 
>> The main advantage of BLE over BT is that it uses much less power, with
>> a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
>> be even greater and connection latency lower than BT. For payment
>> purposes the lower bandwidth isn't much of a hit.
> 
> I'm all for extending the BT: scheme to Bluetooth LE. If you have
> ideas how this can be done please let us know. I haven't had a chance to
> play around with LE because none of my devices support it.
> 
> I suspect the way how Bluetooth LE transfers files (like payment
> requests) is opening a plain old Bluetooth socket. If this is true, I'm
> afraid Bluetooth LE would not add anything for sending the BIP70
> messages back and forth. Note signed payment requests can easily be 4 kB
> in size, so speed *does* matter.

Hi Andreas,

I haven't expressed any preference for BLE, just answering questions
that were raised about it. The main thing that BLE brings to the table
is increased battery life, but with larger transfers that benefit is
reduced.

e



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

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Andreas Schildbach]

On 02/06/2015 02:40 AM, Andy Schroder wrote:

> Where is a more appropriate place to discuss the other issues you have
> at length?

What's wrong with this mailing list?



--
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

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Andreas Schildbach]

On 02/06/2015 01:36 AM, Eric Voskuil wrote:

> The main advantage of BLE over BT is that it uses much less power, with
> a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
> be even greater and connection latency lower than BT. For payment
> purposes the lower bandwidth isn't much of a hit.

I'm all for extending the BT: scheme to Bluetooth LE. If you have
ideas how this can be done please let us know. I haven't had a chance to
play around with LE because none of my devices support it.

I suspect the way how Bluetooth LE transfers files (like payment
requests) is opening a plain old Bluetooth socket. If this is true, I'm
afraid Bluetooth LE would not add anything for sending the BIP70
messages back and forth. Note signed payment requests can easily be 4 kB
in size, so speed *does* matter.



--
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

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Eric Voskuil]

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 possible for this bluetooth
> application considering the connection is not yet encrypted (mentioned
> below), and even if it were, it seems like it is always going to be
> better in case there is some vulnerability. From my testing with a
> bluetooth radio inside my metal cabinet, the range is ~5 meters, which
> is more than enough.
> 
> However, the connection is actually a bit slow when the whole
> certificate chain is included (~3-4s). You can sort of see this in my
> video (http://youtu.be/kkVAhA75k1Y?t=7m39s). A lot of the time is
> actually spent verifying the signature, and I'm not sure how much of it
> is doing the fetching (I haven't done any detailed timings using "adb
> logcat" and looking at the log entries), but I do know it is a little
> slower than an HTTPS payment request fetch over wifi (~2-3s). The reason
> I know most of the time is the signature verification is because an
> HTTPS payment request fetch over wifi and verification using breadwallet
> on apple is much faster (<1s) than HTTPS payment request on bitcoin
> wallet on android (apparently apple has a significantly more optimized
> signature verification algorithm). Bottom line is that there may be ~1s
> time transferring the data with this current bluetooth connection. Not
> sure how slow it will be with the BLE connection. Time is everything in
> a point of sale application.
> 
> So, I guess what I am saying is it seems like the lower speed and range
> gain with bluetooth low energy are not a benefit in my opinion. I'm not
> sure that the latency gain will be a benefit either unless the speed
> issues I am noticing with regular bluetooth are actually a latency issue
> with just getting the connection established, or actually transmitting
> the payment request data. How much power is going to be used for just a
> few second payment? It's not like the bluetooth connection is maintained
> for a long time like it may be in other non bitcoin use cases.
> 
> 
> Where is a more appropriate place to discuss the other issues you have
> at length?



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

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Andy Schroder]

Hello,

I personally would prefer as low of range as possible for this bluetooth 
application considering the connection is not yet encrypted (mentioned 
below), and even if it were, it seems like it is always going to be 
better in case there is some vulnerability. From my testing with a 
bluetooth radio inside my metal cabinet, the range is ~5 meters, which 
is more than enough.


However, the connection is actually a bit slow when the whole 
certificate chain is included (~3-4s). You can sort of see this in my 
video (http://youtu.be/kkVAhA75k1Y?t=7m39s). A lot of the time is 
actually spent verifying the signature, and I'm not sure how much of it 
is doing the fetching (I haven't done any detailed timings using "adb 
logcat" and looking at the log entries), but I do know it is a little 
slower than an HTTPS payment request fetch over wifi (~2-3s). The reason 
I know most of the time is the signature verification is because an 
HTTPS payment request fetch over wifi and verification using breadwallet 
on apple is much faster (<1s) than HTTPS payment request on bitcoin 
wallet on android (apparently apple has a significantly more optimized 
signature verification algorithm). Bottom line is that there may be ~1s 
time transferring the data with this current bluetooth connection. Not 
sure how slow it will be with the BLE connection. Time is everything in 
a point of sale application.


So, I guess what I am saying is it seems like the lower speed and range 
gain with bluetooth low energy are not a benefit in my opinion. I'm not 
sure that the latency gain will be a benefit either unless the speed 
issues I am noticing with regular bluetooth are actually a latency issue 
with just getting the connection established, or actually transmitting 
the payment request data. How much power is going to be used for just a 
few second payment? It's not like the bluetooth connection is maintained 
for a long time like it may be in other non bitcoin use cases.



Where is a more appropriate place to discuss the other issues you have 
at length?



Andy Schroder

On 02/05/2015 07:36 PM, Eric Voskuil wrote:

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 links now I'm encouraged, but I see several things that I'd
like to discuss at greater length than is appropriate here.

The main advantage of BLE over BT is that it uses much less power, with
a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
be even greater and connection latency lower than BT. For payment
purposes the lower bandwidth isn't much of a hit.

e

On 02/05/2015 03:38 PM, Andy Schroder wrote:

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
advantage of using bluetooth low energy over standard bluetooth (I'm not
well versed in bluetooth low energy)? This NFC coupled approach seems to
avoid a lot of issues with identifying the correct payee. You can see
this proposed scheme demonstrated in action in a POS application in the
video link below which demonstrates it with my fuel pump and Andreas
Schildbach's wallet.

There was a small discussion that occurred after my original
announcement below. If you are new to this e-mail list, you can find an
archive of those few replies here:
https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html

Since this original announcement, a few improvements have been made to
the proposal:

  1. Improved documentation and explanation of the use cases in
 Schildbach's wallet's wiki
  1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests
  2. Issue with the payment_url field has resolved by changing to a
 repeated field and requiring the wallet to search for the protocol
 they want to use, rather than expecting it to be a certain element
 number in the list.
  1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki


Although there are some interesting use cases of Airbitz's proposal's
work flow, tapping an NFC radio with a 5 mm range requires much less
brain power and time than picking the correct name on the app's screen.
The manual name picking is going to be especially crazy in a very
congested location. The payer isn't ever going to want to have to try
and figure out what register or payment terminal they are at for most
applications I would ever use.

I'd like to see something happen with this technology. I've also noticed
that micropayment channels have little formality to being established
practically and it would be awesome if they could

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Eric Voskuil]

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 links now I'm encouraged, but I see several things that I'd
like to discuss at greater length than is appropriate here.

The main advantage of BLE over BT is that it uses much less power, with
a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
be even greater and connection latency lower than BT. For payment
purposes the lower bandwidth isn't much of a hit.

e

On 02/05/2015 03:38 PM, Andy Schroder wrote:
> 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
> advantage of using bluetooth low energy over standard bluetooth (I'm not
> well versed in bluetooth low energy)? This NFC coupled approach seems to
> avoid a lot of issues with identifying the correct payee. You can see
> this proposed scheme demonstrated in action in a POS application in the
> video link below which demonstrates it with my fuel pump and Andreas
> Schildbach's wallet.
> 
> There was a small discussion that occurred after my original
> announcement below. If you are new to this e-mail list, you can find an
> archive of those few replies here:
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
> 
> Since this original announcement, a few improvements have been made to
> the proposal:
> 
>  1. Improved documentation and explanation of the use cases in
> Schildbach's wallet's wiki
>  1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests
>  2. Issue with the payment_url field has resolved by changing to a
> repeated field and requiring the wallet to search for the protocol
> they want to use, rather than expecting it to be a certain element
> number in the list.
>  1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
> 
> 
> Although there are some interesting use cases of Airbitz's proposal's
> work flow, tapping an NFC radio with a 5 mm range requires much less
> brain power and time than picking the correct name on the app's screen.
> The manual name picking is going to be especially crazy in a very
> congested location. The payer isn't ever going to want to have to try
> and figure out what register or payment terminal they are at for most
> applications I would ever use.
> 
> I'd like to see something happen with this technology. I've also noticed
> that micropayment channels have little formality to being established
> practically and it would be awesome if they could be managed over
> bluetooth as well. Maybe more improvements to the payment protocol can
> simultaneously result (and also extended to bluetooth) that embrace the
> establishment of micropayment channels.
> 
> 
> 
> Andy Schroder
> 
> On 10/17/2014 03:58 PM, Andy Schroder wrote:
>> Hello,
>>
>> I'd like to introduce two proposed BIPs. They are primarily focused on
>> implementing the payment protocol using bluetooth connections. I've
>> been working on automated point of sale devices and bluetooth
>> communication is critical in my mind due to the potential lack of
>> internet access at many points of sale, either due to lack of cellular
>> internet coverage, lack of payee providing wireless internet, and/or
>> due to financial constraints of the payer prohibiting them from
>> maintaining a cellular internet service plan. These BIPs are largely
>> modeled after the current functionality of Andreas Schildbach's
>> android Bitcoin Wallet's bluetooth capability. I've discussed the
>> communication scheme with him in depth and believe these proposals to
>> clearly and accurately represent the communication scheme.
>>
>> There is also an additional &h= parameter added to the bitcoin: URI
>> scheme which applies to both bluetooth and http payment protocol
>> requests which allows for a hash of the payment request to be
>> included. This hash was proposed by Andreas as an amendment to BIP72,
>> but others preferred not to amend BIP72 since it has already been put
>> into place. The current version of Schildbach's bitcoin wallet already
>> supports the "h parameter".
>>
>> I'd appreciate feedback from everyone, particularly wallet developers
>> as widespread bluetooth support among wallets is very important to me.
>> I'm also very new to this mailing list as well as the BIP writing
>> process, so I'd appreciate your understanding if my conventions are
>> not standard. I am currently using the naming conventions "TBIP", so
>> that I can propose /temporary/ BIP numbers, and cross reference
>> between the two. Obviously these will

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Andy Schroder]

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 
advantage of using bluetooth low energy over standard bluetooth (I'm not 
well versed in bluetooth low energy)? This NFC coupled approach seems to 
avoid a lot of issues with identifying the correct payee. You can see 
this proposed scheme demonstrated in action in a POS application in the 
video link below which demonstrates it with my fuel pump and Andreas 
Schildbach's wallet.


There was a small discussion that occurred after my original 
announcement below. If you are new to this e-mail list, you can find an 
archive of those few replies here: 
https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html


Since this original announcement, a few improvements have been made to 
the proposal:


1. Improved documentation and explanation of the use cases in
   Schildbach's wallet's wiki
1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests
2. Issue with the payment_url field has resolved by changing to a
   repeated field and requiring the wallet to search for the protocol
   they want to use, rather than expecting it to be a certain element
   number in the list.
1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki


Although there are some interesting use cases of Airbitz's proposal's 
work flow, tapping an NFC radio with a 5 mm range requires much less 
brain power and time than picking the correct name on the app's screen. 
The manual name picking is going to be especially crazy in a very 
congested location. The payer isn't ever going to want to have to try 
and figure out what register or payment terminal they are at for most 
applications I would ever use.


I'd like to see something happen with this technology. I've also noticed 
that micropayment channels have little formality to being established 
practically and it would be awesome if they could be managed over 
bluetooth as well. Maybe more improvements to the payment protocol can 
simultaneously result (and also extended to bluetooth) that embrace the 
establishment of micropayment channels.




Andy Schroder

On 10/17/2014 03:58 PM, Andy Schroder wrote:

Hello,

I'd like to introduce two proposed BIPs. They are primarily focused on 
implementing the payment protocol using bluetooth connections. I've 
been working on automated point of sale devices and bluetooth 
communication is critical in my mind due to the potential lack of 
internet access at many points of sale, either due to lack of cellular 
internet coverage, lack of payee providing wireless internet, and/or 
due to financial constraints of the payer prohibiting them from 
maintaining a cellular internet service plan. These BIPs are largely 
modeled after the current functionality of Andreas Schildbach's 
android Bitcoin Wallet's bluetooth capability. I've discussed the 
communication scheme with him in depth and believe these proposals to 
clearly and accurately represent the communication scheme.


There is also an additional &h= parameter added to the bitcoin: URI 
scheme which applies to both bluetooth and http payment protocol 
requests which allows for a hash of the payment request to be 
included. This hash was proposed by Andreas as an amendment to BIP72, 
but others preferred not to amend BIP72 since it has already been put 
into place. The current version of Schildbach's bitcoin wallet already 
supports the "h parameter".


I'd appreciate feedback from everyone, particularly wallet developers 
as widespread bluetooth support among wallets is very important to me. 
I'm also very new to this mailing list as well as the BIP writing 
process, so I'd appreciate your understanding if my conventions are 
not standard. I am currently using the naming conventions "TBIP", so 
that I can propose /temporary/ BIP numbers, and cross reference 
between the two. Obviously these will change if the BIPs are formally 
adopted. You can find a copy of these proposed BIPs at the following 
links:


  * https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
  * https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki


If you are interested, you can see a demonstration of many of the 
proposed features using Schildbach's wallet and my fuel pump in a 
video I recently created: https://youtu.be/kkVAhA75k1Y . The main 
thing not implemented is multiple URLs for the payment protocol, so, 
as a hack, I'm just presenting https vi QR code and bluetooth via NFC 
on my fuel pump for now.




There are a few known issues that could be improved to this bluetooth 
communication scheme as well as the general payment protocol and 
myself and Andreas would like to receive feedback regarding concerns 
and potential solutions. Some

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Justus Ranvier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/20/2014 12:50 PM, Mike Hearn wrote:
> One thing this brings up is the never-resolved issue of whether
> BIPs should document how we'd *like* things to work, or how things
> *actually do* work. BIP32 is an example of the former - it was new
> technology and the spec was finalised before any wallets actually
> implemented it. BIP 44 is an example of the latter, it basically
> documents how myTREZOR works and as such there was minimal or no
> scope for changes to it. Of course both kinds of document are
> valuable.

You also have things like BIP43 that encourage people to reserve BIP
numbers to avoid namespace collisions even if their work does not
affect any other project.

There should be an efficient process for informational BIPs of this type.

- -- 
Justus Ranvier   | Monetas 
  | Public key ID : C3F7BB2638450DB5
 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJUR9T1AAoJEMP3uyY4RQ21ADgH/0JUnkrAzKiBrtFcoXNTEkNl
7npCPY90zQDXk0RN0sV49ralMg/j71azHKmdeH3XHPF2BG3mC4+7TejhJkDEoCoB
fzVyQ/a7MSz3Hnxh0iwx/4p+8A3v6oI6h3yDJeCrwdMudGYA2OfyQuFdrSuchHp6
j0yJpdxxEwtc9A/7SKk5R7yrLqeeLs4OCk2Ep8mZfCQyWssXvlJzd0IDvYZiUHrM
jwLgDCAUNIotEqF4sPzxUMCUkQH3okeVhND/WvoDh8EIrE6l48I19CfDax3gJUU+
4eI5Ooba3SRu5a8cf3V/lgtdbpJJ4i1UdpcjeWNAz1w/P1NVrWN4uJgzUilh6zU=
=OWdW
-END PGP SIGNATURE-


0x38450DB5.asc
Description: application/pgp-keys
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Mike Hearn]

>
> I'm not a cryptography expert, but why not just wrap the bluetooth
> connection with SSL and not reimplement ECDH? Is this
>
hard to do with android/java?
>

Not at all, it should be very easy in Java because of how the SSL API is
designed. I'd worry more about non-Java platforms.

However, SSL is extremely large, old and complicated. We use it on the web
because of a mix of its feature set and legacy concerns. When discussing
encrypted connections in the past, there has been a desire to avoid SSL
because of these issues and do something much simpler and home grown. Of
course, part of the reason SSL is so convoluted is because cryptography
evolves over time, and thus it's not 100% clear to me that a simple
home-rolled crypto link would avoid falling into the same traps as SSL
eventually.

But, at least for now, it's probably more secure and more robust to not use
SSL.


> This sounds great, but I thought it is not desired to divulge a bitcoin
> public key until the time of signing a transaction. Isn't that the whole
> point of having a public key hash and never reusing addresses?
>

Eh, no. Satoshi originally introduced key hashing simply to make shorter
and easier to type destinations. Actually he envisioned most payments being
routed by IP address, where Bitcoin would just connect to the other node
and request a public key directly. There's no problem with the sender
knowing the public key of the address included in the URI.


> This could be resolved by the payee immediately sending the payment to
> another address after receiving it, but that is kind of a waste of a
> transaction. Also, I would love a less PKI dependent way to authenticate a
> transaction between the two parties, but I was trying to minimize the
> discussion of general payment protocol modifications in this announcement.
>

Alternative PKIs would be a topic for another thread, indeed. But I doubt
you will get anywhere. There are no usable alternatives to the SSL PKI. I
wrote an article on the topic here, you may find it useful:

https://medium.com/@octskyward/why-you-think-the-pki-sucks-b64cf5912aa7

It summarises why BIP70 uses the PKI.


> We can do something like this, I guess. The issue I mentioned about the
> message headers being inconsistent will have to be fixed though to to do
> this. However, is anyone even using the HTTP base failure signal (I don't
> even know what it is)?
>

It's "Respond with 500 Internal Server Error" pretty much.

Originally the idea of BIP70 was that clients would not broadcast
transactions. They would submit them to the merchant for broadcast. If the
merchant didn't like the payment for some reason (e.g. paying with a non
standard transaction or with lots of dust), they could just return an error.

Unfortunately Bitcoin Core does broadcast transactions simultaneously.
Additionally, whilst other wallets  did not, one major payment processor
had a very unreliable BIP70 payment_url endpoint for a while, whilst
broadcasting a tx via the p2p network was fully functioning. So to work
around bugs in this one payment processor some other wallets have started
broadcasting the payment tx simultaneously as well.

This means a receiver cannot meaningfully reject a payment. Some wallets
will send it anyway, via the p2p network.


> and a h= parameter, and Schildbach's wallet does accept the payment request
>

I suspect it won't work if you leave out the non-standard h= parameter.

WRT the merge avoidance - there's an article here on how it's meant to work:

https://medium.com/@octskyward/merge-avoidance-7f95a386692f

It's totally OK for you to specify the amounts you want to avoid merges in
your own wallet. The sending wallet could (but none do today) then pay with
multiple transactions.

Your case is really weird because you aren't actually requesting a specific
amout of money. I recall that there's some reason for this, from your
video, but suddenly it escapes me. Because the user scans the payment
request before pumping?


> I don't trust HTTPS for a number of reasons.
>

I disagree with all your reasons (e.g. there is nothing wrong with
outsourcing payment processing and it doesn't have to imply the user sees
an incorrect name), and I believe you should trust the PKI a lot more than
you do. If you try and build a better replacement, I think you'll discover
it's a lot harder than you imagine.

Regardless, I am not against an *optional* tighter binding between URI and
payment request, mostly because it's useful for the cases where signing
with a cert isn't possible. But the simple/obvious "embed a hash of it in
the URI" is inefficient, not compatible with the current specs, can make QR
codes harder to scan, and forces you to format your payment request up
front rather than generating it on demand.


> The primary reason he does not have this in the master branch is because
> the payment protocol only supports signing of payment requests via PKI, and
> it is difficult for a user to install a PKI signed certif

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Andy Schroder]

Hello Mike,

Thanks for the feedback. I have indicated some replies below...

Andy Schroder

On 10/20/2014 08:50 AM, Mike Hearn wrote:

Hey Andy,

Thanks for starting this discussion!

One thing this brings up is the never-resolved issue of whether BIPs 
should document how we'd /like/ things to work, or how things 
/actually do/ work. BIP32 is an example of the former - it was new 
technology and the spec was finalised before any wallets actually 
implemented it. BIP 44 is an example of the latter, it basically 
documents how myTREZOR works and as such there was minimal or no scope 
for changes to it. Of course both kinds of document are valuable.


Currently these specs document how Andreas' app already works. Whilst 
preserving compatibility with existing Android apps is surely useful, 
having a well designed protocol is also good. The current protocol has 
several problems. I don't know which is more important right now and 
don't have a strong opinion on that. My gut feeling is that these 
documents should possibly be just wiki pages on Andreas' github. Then 
if the protocol is brought to a point where it seems pretty good, 
maybe it can be BIPped at that point. Alternatively, if developers of 
other wallet apps feel they'd like a BIP right now even in the current 
state, that would be a very important data point.



Whatever you all want to do here is fine with me. I am new to this 
process, so I have no preference. The payment_url portion is not 
actually part of "Bitcoin Wallet" yet though.





Re: the actual specs:

  * There may seem to be some inconsistency in the connection
header messages

IMHO we could live with that. Although Android apps are updatable, 
perfect header format is probably not worth the inevitable hassle and 
transition period that would result.


That's kind of what Schildbach and I were thinking so it is why we left 
the proposed spec defined as his app currently functions.



  * The current method uses an unauthenticated bluetooth
connection for bluetooth 2.1

This on the other hand is not excellent. This is actually my fault - 
the first Bluetooth support in Bitcoin Wallet for Android was written 
by me in a frantic Berlin hackathon over a weekend. We barely got it 
working at all by the end, so doing encryption/auth was out of the 
question. Then I went back to more important tasks and what got 
shipped was a cleaned up/robustified version of that.


Re: hash. I'm not a fan of this approach. For one, in future there 
might not even BE a uri involved, e.g. consider the Square style UX 
where the merchant is broadcasting an endpoint via BLE and the phone 
just automagically connects, sees a trusted merchant and pays. Super 
slick, we definitely want it - but no URI. Then of course there's the 
usual QR code size limitations.



"Bitcoin Wallet" currently does a similar thing by submitting a payment 
request via NFC and skipping the bitcoin URI. This works just fine in 
conjunction with bitcoin: URI support. I'm not doing it this way on my 
fuel pump (still submitting a bitcoin: URI), because I don't think any 
other wallets (other than "Bitcoin Wallet" derivatives) support such a 
feature and because I'm not sure if signed payment requests can be 
transmitted over NFC well because the message may be too large when the 
certificate chain is included.


My point is, you can have both and if you are going to it doesn't hurt 
to include the h= parameter for cases when a bitcoin: URI will still be 
used.





Encrypting/authing the connection at the app layer does not have to be 
difficult. What we really need/want, is a simple lightweight library 
that does an ECDH key agreement using secp256k1, and then does 
AES+HMAC on framed messages. Such a protocol would be useful not only 
for this use case, but perhaps for encrypting/authing the p2p protocol 
in future as well.


I'm not a cryptography expert, but why not just wrap the bluetooth 
connection with SSL and not reimplement ECDH? Is this hard to do with 
android/java?





Once the encrypted connection is set up above the Bluetooth layer, the 
payment protocol request can then be signed either with a regular 
Bitcoin key that was in the Bitcoin URI as the payment address (when a 
URI is available), thus linking the request to the URI without adding 
any additional data by doubling up the backwards compatibility 
support. Or if there's no URI, then of course, the payment request 
must be PKI signed and the signed PaymentDetails structure can contain 
a copy of the public key that was used to set up the connection, thus 
binding the connection to a PKI identity and ensuring you're not 
talking to a MITM.


This sounds great, but I thought it is not desired to divulge a bitcoin 
public key until the time of signing a transaction. Isn't that the whole 
point of having a public key hash and never reusing addresses? This 
could be resolved by the payee immediately sending the payment to 
another address 

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Mike Hearn]

Hey Andy,

Thanks for starting this discussion!

One thing this brings up is the never-resolved issue of whether BIPs should
document how we'd *like* things to work, or how things *actually do* work.
BIP32 is an example of the former - it was new technology and the spec was
finalised before any wallets actually implemented it. BIP 44 is an example
of the latter, it basically documents how myTREZOR works and as such there
was minimal or no scope for changes to it. Of course both kinds of document
are valuable.

Currently these specs document how Andreas' app already works. Whilst
preserving compatibility with existing Android apps is surely useful,
having a well designed protocol is also good. The current protocol has
several problems. I don't know which is more important right now and don't
have a strong opinion on that. My gut feeling is that these documents
should possibly be just wiki pages on Andreas' github. Then if the protocol
is brought to a point where it seems pretty good, maybe it can be BIPped at
that point. Alternatively, if developers of other wallet apps feel they'd
like a BIP right now even in the current state, that would be a very
important data point.

Re: the actual specs:

>
>- There may seem to be some inconsistency in the connection header
>messages
>
> IMHO we could live with that. Although Android apps are updatable, perfect
header format is probably not worth the inevitable hassle and transition
period that would result.

>
>- The current method uses an unauthenticated bluetooth connection for
>bluetooth 2.1
>
> This on the other hand is not excellent. This is actually my fault - the
first Bluetooth support in Bitcoin Wallet for Android was written by me in
a frantic Berlin hackathon over a weekend. We barely got it working at all
by the end, so doing encryption/auth was out of the question. Then I went
back to more important tasks and what got shipped was a cleaned
up/robustified version of that.

Re: hash. I'm not a fan of this approach. For one, in future there might
not even BE a uri involved, e.g. consider the Square style UX where the
merchant is broadcasting an endpoint via BLE and the phone just
automagically connects, sees a trusted merchant and pays. Super slick, we
definitely want it - but no URI. Then of course there's the usual QR code
size limitations.

Encrypting/authing the connection at the app layer does not have to be
difficult. What we really need/want, is a simple lightweight library that
does an ECDH key agreement using secp256k1, and then does AES+HMAC on
framed messages. Such a protocol would be useful not only for this use
case, but perhaps for encrypting/authing the p2p protocol in future as well.

Once the encrypted connection is set up above the Bluetooth layer, the
payment protocol request can then be signed either with a regular Bitcoin
key that was in the Bitcoin URI as the payment address (when a URI is
available), thus linking the request to the URI without adding any
additional data by doubling up the backwards compatibility support. Or if
there's no URI, then of course, the payment request must be PKI signed and
the signed PaymentDetails structure can contain a copy of the public key
that was used to set up the connection, thus binding the connection to a
PKI identity and ensuring you're not talking to a MITM.

I suspect that this is not anywhere near as hard to implement as one might
think. ECDH is not a complex protocol. You certainly don't need full blown
HTTPS involved.

>
>- There is no acknowledgement failure message possible in the payment
>protocol, only an acknowledgement message or lack of acknowledgement
>message. This issue seems to be a concern and as a result, the memo field
>is used to send an "ack" or "nack" in Schildbach's wallet. Can we add a
>boolean status field to the payment acknowledgement message?
>
> Ugh. I did want a way to indicate failure when we designed BIP70, but I
can't remember why one wasn't included in the final spec. I think we
decided the containing protocol could do this instead (normally HTTP).

Abusing the memo field is definitely the wrong thing to do! Rather the
Bluetooth specific encapsulation protocol should have a notion of failure.

>
>- I'd personally like a new optional boolean field added to the
>"PaymentDetails" portion of the "PaymentRequest" to allow for the payer's
>wallet to match the "Output" optional "amount" fields as a total amount of
>all Outputs, rather than requiring the amount for each output to be matched
>exactly.
>
> Extending BIP70 with more negotiable privacy features is a different
effort, let's not discuss that as part of Bluetooth support.

Besides, no wallet uses even the existing support for merge avoidance in
BIP70. In fact Andreas' wallet is one of the blocking factors here because
it violates the specs by requiring the BIP70 request to have only a single
output that matches the address specified in the URI. All becaus

[Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Andy Schroder]

Hello,

I'd like to introduce two proposed BIPs. They are primarily focused on 
implementing the payment protocol using bluetooth connections. I've been 
working on automated point of sale devices and bluetooth communication 
is critical in my mind due to the potential lack of internet access at 
many points of sale, either due to lack of cellular internet coverage, 
lack of payee providing wireless internet, and/or due to financial 
constraints of the payer prohibiting them from maintaining a cellular 
internet service plan. These BIPs are largely modeled after the current 
functionality of Andreas Schildbach's android Bitcoin Wallet's bluetooth 
capability. I've discussed the communication scheme with him in depth 
and believe these proposals to clearly and accurately represent the 
communication scheme.


There is also an additional &h= parameter added to the bitcoin: URI 
scheme which applies to both bluetooth and http payment protocol 
requests which allows for a hash of the payment request to be included. 
This hash was proposed by Andreas as an amendment to BIP72, but others 
preferred not to amend BIP72 since it has already been put into place. 
The current version of Schildbach's bitcoin wallet already supports the 
"h parameter".


I'd appreciate feedback from everyone, particularly wallet developers as 
widespread bluetooth support among wallets is very important to me. I'm 
also very new to this mailing list as well as the BIP writing process, 
so I'd appreciate your understanding if my conventions are not standard. 
I am currently using the naming conventions "TBIP", so that I can 
propose /temporary/ BIP numbers, and cross reference between the two. 
Obviously these will change if the BIPs are formally adopted. You can 
find a copy of these proposed BIPs at the following links:


 * https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
 * https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki


If you are interested, you can see a demonstration of many of the 
proposed features using Schildbach's wallet and my fuel pump in a video 
I recently created: https://youtu.be/kkVAhA75k1Y . The main thing not 
implemented is multiple URLs for the payment protocol, so, as a hack, 
I'm just presenting https vi QR code and bluetooth via NFC on my fuel 
pump for now.




There are a few known issues that could be improved to this bluetooth 
communication scheme as well as the general payment protocol and myself 
and Andreas would like to receive feedback regarding concerns and 
potential solutions. Some of the known issues are:


 * There may seem to be some inconsistency in the connection header
   messages between the payment request connection and the payment
   connection. This is largely because it is how Andreas originally
   implemented the communication and is hesitant to change it since
   there are many instances of is software already deployed that
   implement this scheme.
 * The current method uses an unauthenticated bluetooth connection for
   bluetooth 2.1 and newer devices (subject to man in the middle
   attacks, but not passive eavesdroppers), and an unsecure and
   unauthenticated connection for older devices. The known concerns
   here are that someone within 100 meters of the payer could track the
   bitcoin addresses used for the transaction and could possibly
   replace the refund address by submitting a forged payment message to
   the payee. Requiring bluetooth 2.1 and authenticating the connection
   out of band unfortunately don't seem to be as straightforward/simple
   of a task with most bluetooth libraries (although I'd love for
   someone to prove me wrong). It's possible this communication scheme
   could be extended to use an https "like" protocol that would not
   care if the underlying bluetooth connection is authenticated or
   encrypted. It's actually possible that http over a bluetooth socket
   (instead of tcp socket) could be implemented, however it is
   presently uncertain whether this would be too slow, too much
   overhead (both on the devices software and communication), or if
   http could easily be run over bluetooth sockets on all platforms.
 * There is no acknowledgement failure message possible in the payment
   protocol, only an acknowledgement message or lack of acknowledgement
   message. This issue seems to be a concern and as a result, the memo
   field is used to send an "ack" or "nack" in Schildbach's wallet. Can
   we add a boolean status field to the payment acknowledgement message?
 * I'd personally like a new optional boolean field added to the
   "PaymentDetails" portion of the "PaymentRequest" to allow for the
   payer's wallet to match the "Output" optional "amount" fields as a
   total amount of all Outputs, rather than requiring the amount for
   each output to be matched exactly. As it currently is, the payee can
   specify multiple receiving addresses in order to require a payer
   split up the payments so th