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

• 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.
• 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).
  
• 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."

-- 
Andy Schroder