Here are my complementary thoughts after working on the payment protocol
on the merchant side at BitPay.

The most important missing piece of the payment protocol is that is has
no concept of the status of a payment after it has been made. What if
the payment is too little? Too much? What if it is never confirmed? What
if it is confirmed, but very late? These are regular occurrences at
BitPay (although hopefully they will be a lot fewer after the payment
protocol is widely adopted).

One way to handle this would be to add another type of message, say with
content-type bitcoin-paymentstatus, that can return the merchant's view
of the status of the transaction(s). Are the transactions under or
overpaid? Are they confirmed? How many confirmations? Is the payment
"accepted" even if the transactions aren't confirmed?

I think it would be great if wallets could check the status of a
payment, and if anything goes wrong, request a refund, all within the
payment protocol.

The payment protocol is also the perfect opportunity to implement merge
avoidance to increase customer and merchant privacy. The merchant can
simply deliver multiple outputs in the payment details, say 10 or so,
and the customer can spend multiple outputs to those outputs in separate
transactions. It would be great if BitPay could work with wallet authors
to make merge avoidance a reality in the near-term.

Merge avoidance would increase the need to have a bitcoin-paymentstatus
message since it's possible that some, but not all, of the transactions
would confirm, and so knowing the status of payment would be a complex
question that should be handled automatically by the software.

On an unrelated note, X.509 is a terrible standard that should be
abandoned as quickly as possible. BitPay is working on a new standard
based on bitcoin-like addresses for authentication. It would be great if
we could work with the community to establish a complete, decentralized
authentication protocol. The sooner we can evolve beyond X.509 the better.

One more thing. The new bitcoin URI in BIP 72 is extremely long and
makes for very dense QR codes. BitPay has proposed a new standard, BIP
73, for shorter URIs and less dense QR codes. We hope wallet authors
will implement this better standard.

My response to Andreas' thoughts:

On 2/18/14, 12:31 PM, Andreas Schildbach wrote:
> I'm starting a thread on proposed changes on BIP70 based on my
> experience in implementing the payment protocol in Bitcoin Wallet:
> 
> - certificate chain in pki_data: I think it should be required that is
> most contain the first certificate PLUS all intermediate certificates
> (if any), but NOT the root certificate. Reason: We want to be able to
> verify offline.

So long as the root certificate remains an optional addition, this seems
like a good idea. My experience with tls in node is that it is required
for the root certificate to be present, so we don't want to require that
the root certificate be absent, since that would make it painful to make
code that is interoperable between the two. IIRC setting
rejectUnauthorized=true will reject connections that do not deliver the
root certificate, so allowing the root certificate to be present would
be compatible with this and presumably other tls code.

Would be great if someone with more experience with tls weighed in on
whether the root certificate can/should be present.

> 
> - definition of timezone: Its not clear if times (e.g. expires) are in
> UTC or local. I suggest to require UTC. If if we can't agree on this,
> there should be a sentence about timezones in the spec.

The world needs to abandon timezones altogether for everything and only
use UTC. So, agreed. Require UTC.

> 
> (probably more to be added...)
> 
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

-- 
Ryan X. Charles
Software Engineer, BitPay