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

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

[Andy Schroder]

[-- Attachment #1.1: Type: text/plain, Size: 8399 bytes --]

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 that when the payee then goes to spend the
    funds later, they don't necessarily have to give their payees as
    much knowledge of their balances and spending and receiving habits
    and sources. As the payment protocol currently is requiring all
    output amounts to be matched exactly for each output, there is no
    flexibility given to the payer in order to reduce a merging or
    unnecessary diverging of account funds, which can reduce the privacy
    of both the payer and the payee. If the payee were given the option
    to allow the payer the option to divide the amounts amount the
    outputs intelligently, there can be some privacy gained.
  * Amount of data stored in QR codes may be getting large when a
    backwards compatible URL is used (for wallets that don't support the
    payment protocol) and can be difficult to scan with outdoor screens
    that have an extra weather resistant pane when in direct sunlight.
  * The number of offline transactions of a wallet is limited to the
    known unspent outputs when they go offline. Long term, I'd like to
    see wallet devices that can use systems such as Kryptoradio's DVB-T
    based broadcast (but this will need yet another radio!). Another
    project may be to develop a blockchain query protocol of some kind
    where retailers can provide access to blockchain data so that
    customer's wallets can update their known unspent outputs via
    bluetooth. It's possible such a bluetooth system could be used in
    combination of "Kryptoradio" like broadcasts to provide multiple
    blockchain references.
  * The additional payment_url approach is a bit sloppy of a solution in
    the PaymentDetails portion of the PaymentRequest. It would have been
    ideal to just change this from an optional field to a repeated
    field, however, the backwards compatibility in the protocol buffer
    format will provide the last item in the array for a repeated field
    (to a code that expects it to be an optional field), rather than the
    first. Because of this, backwards compatibility with https payment
    requests wouldn't work if the payment_url field is just changed to a
    repeated field.
      o Possible alternatives to what is described in the proposed BIP
          + Change payment_url to a repeated field and then reverse the
            order of the parameter numbers in the payment_url, compared
            to the bitcoin URL "r parameter".
          + Create an additional, new payment_url_multi repeated field
            (or some better name), and then leave the original
            payment_url field in there for backwards compatibility (and
            then maybe phase it out in the future).
      o Reference
          + https://developers.google.com/protocol-buffers/docs/proto#updating
              # "|optional| is compatible with |repeated|. Given
                serialized data of a repeated field as input, clients
                that expect this field to be |optional| will take the
                last input value if it's a primitive type field or merge
                all input elements if it's a message type field."



Your comments and suggestions would be greatly appreciated.

-- 
Andy Schroder


[-- Attachment #1.2: Type: text/html, Size: 10144 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 8024 bytes --]

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 because he
doesn't trust HTTPS :(

I don't think adding even more privacy stuff to BIP70 makes any sense until
we have implementations that actually exploit the existing support. And to
get there, we must fix Andreas' wallet so it doesn't violate the specs
anymore. Sorry Andreas. I know we argue about this all the time, but it's
really a big problem that your app doesn't obey the specs. It makes
everyone reluctant to use new BIP70 features, because they feel a need to
test with every possible wallet app in case one of them has simply decided
to do their own thing and become deliberately incompatible. And then why
bother, there are more important things to do.

>
>    - Amount of data stored in QR codes may be getting large when a
>    backwards compatible URL is used (for wallets that don't support the
>    payment protocol) and can be difficult to scan with outdoor screens that
>    have an extra weather resistant pane when in direct sunlight.
>
> MAC addresses could be encoded more efficiently, of course, but it seems
unlikely that address-less URIs can be relied upon any time soon - and
besides if the URI needs to bind to an authenticated channel because PKI
signing is not in use, then it makes sense to use that part of the URI to
do so.

>
>    - The number of offline transactions of a wallet is limited to the
>    known unspent outputs when they go offline. Long term, I'd like to see
>    wallet devices that can use systems such as Kryptoradio's DVB-T based
>    broadcast (but this will need yet another radio!).
>
> Given that all interesting mobile devices have sophisticated internet
access radios of various forms, I doubt it's worth putting much effort in
here. Bluetooth for submitting payments makes sense some of the time,
partly for performance and partly because it's more decentralised than
looping in an intermediary HTTPS server to temporarily host a BIP70 request
file. I don't think we should try and invent an entirely new "block chain
internet" though. At any rate, it's a separate effort.

>
>    - The additional payment_url approach is a bit sloppy of a solution in
>    the PaymentDetails portion of the PaymentRequest.
>
> This is only an issue because of the way you define the hashing mechanism.
If you reuse the backwards compatibility address, then the payment_url can
of course be customised based on whatever transport mechanism the request
was fetched over. There is no longer any need to have the payment request
be created (and presumably stored) the moment the QR code is generated.
Besides, that approach has all kinds of messy implementation problems. You
don't know the QR code will *ever* be scanned, but you must have the exact
payment request at the time the QR code is generated. Payment requests
expire, so you have to define some kind of timeout at which point the QR
code itself becomes invalid. Urgh.

Much better to have the PaymentRequest formatted and signed on demand, once
the URI is being resolved. But that means you have to abandon the h=
mechanism.

[-- Attachment #2: Type: text/html, Size: 9991 bytes --]

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

[Andy Schroder]

[-- Attachment #1.1: Type: text/plain, Size: 15534 bytes --]

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


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

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)? What about when new protocols other than 
bluetooth are created? I'm just wondering if it's better to have more 
functionality defined at the payment protocol level so that developers 
have to learn less nuances about each particular protocol they are 
implementing the payment protocol over. The other thing is what if you 
want to indicate a failure, and a reason for that 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.

Understood, I was just throwing this thought out there, but do realize 
it is a separate discussion.

>
> 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 because he doesn't trust HTTPS :(

To be clear, the way I am currently implementing my fuel pump, I am 
specifying 4 payment addresses with no amount requirement and a h= 
parameter, and Schildbach's wallet does accept the payment request, but 
only chooses to use the first payment address (this may have something 
to do with the unspent outputs on my phone though). I believe 
Schildbach's wallet still works if multiple addresses are defined and 
multiple amounts, however, I'm not currently submitting payment requests 
this way because of the merge avoidance constraints mentioned below.

I don't trust HTTPS for a number of reasons. First off, it is way to 
easy to get a signed certificate with no real validation by the 
certificate signer. Second, the current PKI is a target for manipulation 
by surveillance organizations because there are too few parties 
involved. Third, even if you have a signed certificate that is really 
owned by the person they say it is, it's not easy for a payer to quickly 
verify the signer is really the correct one because retailers can 
contract out their payment process to another party, have a central 
office, subsidiary, or be doing business under a name that is not 
necessarily their legal company name. Even if we replace the PKI with 
something more distributed like namecoin, the third option is still 
going to be an issue, which warrants the need for the h= parameter.



>
> I don't think adding even more privacy stuff to BIP70 makes any sense 
> until we have implementations that actually exploit the existing 
> support. And to get there, we must fix Andreas' wallet so it doesn't 
> violate the specs anymore. Sorry Andreas. I know we argue about this 
> all the time, but it's really a big problem that your app doesn't obey 
> the specs. It makes everyone reluctant to use new BIP70 features, 
> because they feel a need to test with every possible wallet app in 
> case one of them has simply decided to do their own thing and become 
> deliberately incompatible. And then why bother, there are more 
> important things to do.


I don't totally understand the background of what you are talking about 
here, but I think the h= parameter may designed to address the issues 
Schildbach has complying with the spec as you mention.


>       * Amount of data stored in QR codes may be getting large when a
>         backwards compatible URL is used (for wallets that don't
>         support the payment protocol) and can be difficult to scan
>         with outdoor screens that have an extra weather resistant pane
>         when in direct sunlight.
>
> MAC addresses could be encoded more efficiently, of course, but it 
> seems unlikely that address-less URIs can be relied upon any time soon 
> - and besides if the URI needs to bind to an authenticated channel 
> because PKI signing is not in use, then it makes sense to use that 
> part of the URI to do so.


PKI is not in use for "Bitcoin Wallet" for providing payment request, 
but it is in use in my fuel dispenser that was demonstrated in the 
video. Actually, I should have clarified in my announcement that 
"Bitcoin Wallet" only allows for bluetooth incoming connections for 
submitting payment, not providing payment requests. Since the payment 
request is unsigned and small, it can just be submitted via NFC (as I 
have mentioned above), and bluetooth isn't really needed. Andreas does 
have a branch that supports this but it is not included in the master 
distribution branch. 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 certificate on android, just for a single peer to peer use 
case. I think for now he just uses that branch to test his functionality 
for fetching bluetooth payment requests from devices like mine (although 
I'm not aware of any other devices that actually exist right now).





>       * The number of offline transactions of a wallet is limited to
>         the known unspent outputs when they go offline. Long term, I'd
>         like to see wallet devices that can use systems such as
>         Kryptoradio's DVB-T based broadcast (but this will need yet
>         another radio!).
>
> Given that all interesting mobile devices have sophisticated internet 
> access radios of various forms, I doubt it's worth putting much effort 
> in here. Bluetooth for submitting payments makes sense some of the 
> time, partly for performance and partly because it's more 
> decentralised than looping in an intermediary HTTPS server to 
> temporarily host a BIP70 request file. I don't think we should try and 
> invent an entirely new "block chain internet" though. At any rate, 
> it's a separate effort.

It is a separate effort, but I was mentioning it because it is related. 
Your comment "Given that all interesting mobile devices have 
sophisticated internet access radios of various forms, I doubt it's 
worth putting much effort in here" makes me believe that you don't 
understand the need for this. If you are to provide a full fledged wifi 
connection to the customer, there would then have to be a very 
sophisticated proxy server that can allow only access to bitcoin nodes, 
and how to do that would be difficult since every node doesn't know all 
of the nodes in the network. You'd also have to be able to make the 
customer's phone automatically connect and disconnect from this service 
without leaving a saved access point name in their wifi access point 
list (otherwise you will have a bunch of them accumulate that you don't 
care about). Having dedicated blockchain access is going to be a 
necessity: everyone doesn't want a cellular internet plan, they can't 
always afford it, and it isn't always available, and as I just 
explained, wifi is currently a cumbersome solution to this problem.

>       * The additional payment_url approach is a bit sloppy of a
>         solution in the PaymentDetails portion of the PaymentRequest.
>
> This is only an issue because of the way you define the hashing 
> mechanism. If you reuse the backwards compatibility address, then the 
> payment_url can of course be customised based on whatever transport 
> mechanism the request was fetched over. There is no longer any need to 
> have the payment request be created (and presumably stored) the moment 
> the QR code is generated. Besides, that approach has all kinds of 
> messy implementation problems. You don't know the QR code will 
> /ever/ be scanned, but you must have the exact payment request at the 
> time the QR code is generated. Payment requests expire, so you have to 
> define some kind of timeout at which point the QR code itself becomes 
> invalid. Urgh.
>
> Much better to have the PaymentRequest formatted and signed on demand, 
> once the URI is being resolved. But that means you have to abandon the 
> h= mechanism.


All this was already known but was not proposed because it does not 
allow you to use the h= parameter. What do you propose to do instead of 
the h= parameter, but still allow for a trust anchor with the payee 
still be maintained? Another option is to do the hashing to the payment 
request before the payment_url is added to the payment request, however, 
this then can allow a hacker to change the payment_url.





[-- Attachment #1.2: Type: text/html, Size: 24303 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 6895 bytes --]

>
> 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 certificate on android,
> just for a single peer to peer use case.
>

Unsigned requests work OK for the phone to phone case, assuming you aren't
actually talking to an imposter.


> If you are to provide a full fledged wifi connection to the customer,
> there would then have to be a very sophisticated proxy server that can
> allow only access to bitcoin nodes, and how to do that would be difficult
> since every node doesn't know all of the nodes in the network.
>

You can just allow port 8333 and rewrite port 80, as most wifi hotspots do
today already.

But my point about this was that all smartphones get internet access from
time to time. In my own life, I've definitely been in cases where I wanted
to *pay* with bitcoins but didn't have good internet access at that exact
moment, e.g. back of a restaurant. I've also been in the situation more
rarely where I wanted to receive coins from someone in front of me, without
good internet access, but Bluetooth already addresses that.

I don't recall ever being in a situation where I had no internet access,
but somehow knew there was a payment waiting for me on the block chain, and
I needed it right now because it was necessary for me to receive that money
in order to pay a bill. That's what the dedicated blockchain radio would
provide, but it seems like a very rare use case.


> All this was already known but was not proposed because it does not allow
> you to use the h= parameter. What do you propose to do instead of the h=
> parameter, but still allow for a trust anchor with the payee still be
> maintained?
>

I think I said already, but maybe am not explaining well. You use the
address that's already in all backwards compatible URIs. The payment
details can be additionally signed with the key corresponding to that
address. Or, that key can be covered by the PKI signature if there is one.
But dual signing is always possible.

[-- Attachment #2: Type: text/html, Size: 10221 bytes --]

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

[Justus Ranvier]

[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]

-----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 <http://monetas.net/>
<mailto:justus@monetas.net>      | 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-----

[-- Attachment #2: 0x38450DB5.asc --]
[-- Type: application/pgp-keys, Size: 14542 bytes --]

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

[Andy Schroder]

[-- Attachment #1.1: Type: text/plain, Size: 11170 bytes --]

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 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 that when the payee then goes to
>     spend the funds later, they don't necessarily have to give their
>     payees as much knowledge of their balances and spending and
>     receiving habits and sources. As the payment protocol currently is
>     requiring all output amounts to be matched exactly for each
>     output, there is no flexibility given to the payer in order to
>     reduce a merging or unnecessary diverging of account funds, which
>     can reduce the privacy of both the payer and the payee. If the
>     payee were given the option to allow the payer the option to
>     divide the amounts amount the outputs intelligently, there can be
>     some privacy gained.
>   * Amount of data stored in QR codes may be getting large when a
>     backwards compatible URL is used (for wallets that don't support
>     the payment protocol) and can be difficult to scan with outdoor
>     screens that have an extra weather resistant pane when in direct
>     sunlight.
>   * The number of offline transactions of a wallet is limited to the
>     known unspent outputs when they go offline. Long term, I'd like to
>     see wallet devices that can use systems such as Kryptoradio's
>     DVB-T based broadcast (but this will need yet another radio!).
>     Another project may be to develop a blockchain query protocol of
>     some kind where retailers can provide access to blockchain data so
>     that customer's wallets can update their known unspent outputs via
>     bluetooth. It's possible such a bluetooth system could be used in
>     combination of "Kryptoradio" like broadcasts to provide multiple
>     blockchain references.
>   * The additional payment_url approach is a bit sloppy of a solution
>     in the PaymentDetails portion of the PaymentRequest. It would have
>     been ideal to just change this from an optional field to a
>     repeated field, however, the backwards compatibility in the
>     protocol buffer format will provide the last item in the array for
>     a repeated field (to a code that expects it to be an optional
>     field), rather than the first. Because of this, backwards
>     compatibility with https payment requests wouldn't work if the
>     payment_url field is just changed to a repeated field.
>       o Possible alternatives to what is described in the proposed BIP
>           + Change payment_url to a repeated field and then reverse
>             the order of the parameter numbers in the payment_url,
>             compared to the bitcoin URL "r parameter".
>           + Create an additional, new payment_url_multi repeated field
>             (or some better name), and then leave the original
>             payment_url field in there for backwards compatibility
>             (and then maybe phase it out in the future).
>       o Reference
>           + https://developers.google.com/protocol-buffers/docs/proto#updating
>               # "|optional| is compatible with |repeated|. Given
>                 serialized data of a repeated field as input, clients
>                 that expect this field to be |optional| will take the
>                 last input value if it's a primitive type field or
>                 merge all input elements if it's a message type field."
>
>
>
> Your comments and suggestions would be greatly appreciated.
>
> -- 
> Andy Schroder
>


[-- Attachment #1.2: Type: text/html, Size: 14171 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 12793 bytes --]

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 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 that when the payee then goes to
>>     spend the funds later, they don't necessarily have to give their
>>     payees as much knowledge of their balances and spending and
>>     receiving habits and sources. As the payment protocol currently is
>>     requiring all output amounts to be matched exactly for each
>>     output, there is no flexibility given to the payer in order to
>>     reduce a merging or unnecessary diverging of account funds, which
>>     can reduce the privacy of both the payer and the payee. If the
>>     payee were given the option to allow the payer the option to
>>     divide the amounts amount the outputs intelligently, there can be
>>     some privacy gained.
>>   * Amount of data stored in QR codes may be getting large when a
>>     backwards compatible URL is used (for wallets that don't support
>>     the payment protocol) and can be difficult to scan with outdoor
>>     screens that have an extra weather resistant pane when in direct
>>     sunlight.
>>   * The number of offline transactions of a wallet is limited to the
>>     known unspent outputs when they go offline. Long term, I'd like to
>>     see wallet devices that can use systems such as Kryptoradio's
>>     DVB-T based broadcast (but this will need yet another radio!).
>>     Another project may be to develop a blockchain query protocol of
>>     some kind where retailers can provide access to blockchain data so
>>     that customer's wallets can update their known unspent outputs via
>>     bluetooth. It's possible such a bluetooth system could be used in
>>     combination of "Kryptoradio" like broadcasts to provide multiple
>>     blockchain references.
>>   * The additional payment_url approach is a bit sloppy of a solution
>>     in the PaymentDetails portion of the PaymentRequest. It would have
>>     been ideal to just change this from an optional field to a
>>     repeated field, however, the backwards compatibility in the
>>     protocol buffer format will provide the last item in the array for
>>     a repeated field (to a code that expects it to be an optional
>>     field), rather than the first. Because of this, backwards
>>     compatibility with https payment requests wouldn't work if the
>>     payment_url field is just changed to a repeated field.
>>       o Possible alternatives to what is described in the proposed BIP
>>           + Change payment_url to a repeated field and then reverse
>>             the order of the parameter numbers in the payment_url,
>>             compared to the bitcoin URL "r parameter".
>>           + Create an additional, new payment_url_multi repeated field
>>             (or some better name), and then leave the original
>>             payment_url field in there for backwards compatibility
>>             (and then maybe phase it out in the future).
>>       o Reference
>>           + https://developers.google.com/protocol-buffers/docs/proto#updating
>>               # "|optional| is compatible with |repeated|. Given
>>                 serialized data of a repeated field as input, clients
>>                 that expect this field to be |optional| will take the
>>                 last input value if it's a primitive type field or
>>                 merge all input elements if it's a message type field."
>>
>>
>>
>> Your comments and suggestions would be greatly appreciated.
>>
>> -- 
>> Andy Schroder
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> 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
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Andy Schroder]

[-- Attachment #1: Type: text/plain, Size: 15281 bytes --]

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 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 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 that when the payee then goes to
>>>      spend the funds later, they don't necessarily have to give their
>>>      payees as much knowledge of their balances and spending and
>>>      receiving habits and sources. As the payment protocol currently is
>>>      requiring all output amounts to be matched exactly for each
>>>      output, there is no flexibility given to the payer in order to
>>>      reduce a merging or unnecessary diverging of account funds, which
>>>      can reduce the privacy of both the payer and the payee. If the
>>>      payee were given the option to allow the payer the option to
>>>      divide the amounts amount the outputs intelligently, there can be
>>>      some privacy gained.
>>>    * Amount of data stored in QR codes may be getting large when a
>>>      backwards compatible URL is used (for wallets that don't support
>>>      the payment protocol) and can be difficult to scan with outdoor
>>>      screens that have an extra weather resistant pane when in direct
>>>      sunlight.
>>>    * The number of offline transactions of a wallet is limited to the
>>>      known unspent outputs when they go offline. Long term, I'd like to
>>>      see wallet devices that can use systems such as Kryptoradio's
>>>      DVB-T based broadcast (but this will need yet another radio!).
>>>      Another project may be to develop a blockchain query protocol of
>>>      some kind where retailers can provide access to blockchain data so
>>>      that customer's wallets can update their known unspent outputs via
>>>      bluetooth. It's possible such a bluetooth system could be used in
>>>      combination of "Kryptoradio" like broadcasts to provide multiple
>>>      blockchain references.
>>>    * The additional payment_url approach is a bit sloppy of a solution
>>>      in the PaymentDetails portion of the PaymentRequest. It would have
>>>      been ideal to just change this from an optional field to a
>>>      repeated field, however, the backwards compatibility in the
>>>      protocol buffer format will provide the last item in the array for
>>>      a repeated field (to a code that expects it to be an optional
>>>      field), rather than the first. Because of this, backwards
>>>      compatibility with https payment requests wouldn't work if the
>>>      payment_url field is just changed to a repeated field.
>>>        o Possible alternatives to what is described in the proposed BIP
>>>            + Change payment_url to a repeated field and then reverse
>>>              the order of the parameter numbers in the payment_url,
>>>              compared to the bitcoin URL "r parameter".
>>>            + Create an additional, new payment_url_multi repeated field
>>>              (or some better name), and then leave the original
>>>              payment_url field in there for backwards compatibility
>>>              (and then maybe phase it out in the future).
>>>        o Reference
>>>            + https://developers.google.com/protocol-buffers/docs/proto#updating
>>>                # "|optional| is compatible with |repeated|. Given
>>>                  serialized data of a repeated field as input, clients
>>>                  that expect this field to be |optional| will take the
>>>                  last input value if it's a primitive type field or
>>>                  merge all input elements if it's a message type field."
>>>
>>>
>>>
>>> Your comments and suggestions would be greatly appreciated.
>>>
>>> -- 
>>> Andy Schroder
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 2395 bytes --]

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?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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?

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1190 bytes --]

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:<mac> 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.

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

[Eric Voskuil]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2084 bytes --]

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

[Peter D. Gray]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 514 bytes --]