<div dir="ltr">Fantastic feedback, thanks Ryan and Andreas!<div><br></div><div>Please don't let me being busy get in the way of progress, so submit pull requests to the BIP (the UTC timezone issue seems obvious and non-controversial) or write up draft specs for extensions.</div>
<div><br></div><div>RE: wallets checking the status of payment: excellent idea. A URL that can be polled to check payment processing status sounds like the right thing to do.</div><div><br></div><div>That feels very similar to the proposal for recurring payments; I think they would be separate mechanisms, but maybe their specs could share some of the same concepts / field names....</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 2:14 PM, Ryan X. Charles <span dir="ltr"><<a href="mailto:ryan@bitpay.com" target="_blank">ryan@bitpay.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here are my complementary thoughts after working on the payment protocol<br>
on the merchant side at BitPay.<br>
<br>
The most important missing piece of the payment protocol is that is has<br>
no concept of the status of a payment after it has been made. What if<br>
the payment is too little? Too much? What if it is never confirmed? What<br>
if it is confirmed, but very late? These are regular occurrences at<br>
BitPay (although hopefully they will be a lot fewer after the payment<br>
protocol is widely adopted).<br>
<br>
One way to handle this would be to add another type of message, say with<br>
content-type bitcoin-paymentstatus, that can return the merchant's view<br>
of the status of the transaction(s). Are the transactions under or<br>
overpaid? Are they confirmed? How many confirmations? Is the payment<br>
"accepted" even if the transactions aren't confirmed?<br>
<br>
I think it would be great if wallets could check the status of a<br>
payment, and if anything goes wrong, request a refund, all within the<br>
payment protocol.<br>
<br>
The payment protocol is also the perfect opportunity to implement merge<br>
avoidance to increase customer and merchant privacy. The merchant can<br>
simply deliver multiple outputs in the payment details, say 10 or so,<br>
and the customer can spend multiple outputs to those outputs in separate<br>
transactions. It would be great if BitPay could work with wallet authors<br>
to make merge avoidance a reality in the near-term.<br>
<br>
Merge avoidance would increase the need to have a bitcoin-paymentstatus<br>
message since it's possible that some, but not all, of the transactions<br>
would confirm, and so knowing the status of payment would be a complex<br>
question that should be handled automatically by the software.<br>
<br>
On an unrelated note, X.509 is a terrible standard that should be<br>
abandoned as quickly as possible. BitPay is working on a new standard<br>
based on bitcoin-like addresses for authentication. It would be great if<br>
we could work with the community to establish a complete, decentralized<br>
authentication protocol. The sooner we can evolve beyond X.509 the better.<br>
<br>
One more thing. The new bitcoin URI in BIP 72 is extremely long and<br>
makes for very dense QR codes. BitPay has proposed a new standard, BIP<br>
73, for shorter URIs and less dense QR codes. We hope wallet authors<br>
will implement this better standard.<br>
<br>
My response to Andreas' thoughts:<br>
<div class=""><br>
On 2/18/14, 12:31 PM, Andreas Schildbach wrote:<br>
> I'm starting a thread on proposed changes on BIP70 based on my<br>
> experience in implementing the payment protocol in Bitcoin Wallet:<br>
><br>
> - certificate chain in pki_data: I think it should be required that is<br>
> most contain the first certificate PLUS all intermediate certificates<br>
> (if any), but NOT the root certificate. Reason: We want to be able to<br>
> verify offline.<br>
<br>
</div>So long as the root certificate remains an optional addition, this seems<br>
like a good idea. My experience with tls in node is that it is required<br>
for the root certificate to be present, so we don't want to require that<br>
the root certificate be absent, since that would make it painful to make<br>
code that is interoperable between the two. IIRC setting<br>
rejectUnauthorized=true will reject connections that do not deliver the<br>
root certificate, so allowing the root certificate to be present would<br>
be compatible with this and presumably other tls code.<br>
<br>
Would be great if someone with more experience with tls weighed in on<br>
whether the root certificate can/should be present.<br>
<div class=""><br>
><br>
> - definition of timezone: Its not clear if times (e.g. expires) are in<br>
> UTC or local. I suggest to require UTC. If if we can't agree on this,<br>
> there should be a sentence about timezones in the spec.<br>
<br>
</div>The world needs to abandon timezones altogether for everything and only<br>
use UTC. So, agreed. Require UTC.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> (probably more to be added...)<br>
><br>
><br>
> ------------------------------------------------------------------------------<br>
> Managing the Performance of Cloud-Based Applications<br>
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.<br>
> Read the Whitepaper.<br>
> <a href="http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk</a><br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
> <a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Ryan X. Charles<br>
Software Engineer, BitPay<br>
</font></span><br>------------------------------------------------------------------------------<br>
Managing the Performance of Cloud-Based Applications<br>
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.<br>
Read the Whitepaper.<br>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>--<br>Gavin Andresen<br>
</div>