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.