Yet more comments (I guess at some point we need to stick a fork in it - or at least move on to implementing a prototype version).
Maybe don't require the payment URI to be HTTPS. If you want to pay a Tor hidden service then HTTPS just adds unnecessary complexity. Just recommend to merchants that they use an encrypted connection and leave it at that. Though it's not strictly necessary, it'd be nice to have defined behavior for if you want to pay more than the requested amount, for a tip. Perhaps rather than "zero value outputs will be ignored" say, "if some outputs have value and others don't, the user will be given the option of overpaying and the extra money will be split evenly between the zero valued outputs". That way a waitress can have the phone add a zero-valued output to her own wallet and that would prompt the wallet software to display some convenient UI for adding on 10% or whatever. receiptURI -> receipt_url ? technically it has to be resolvable so "uri" isn't quite right. "Display the proposed Outputs in as human-friendly a form as possible" .... ??? Surely you'd just display the total amount requested? I don't think it ever makes sense to try and display outputs to the user directly. Re: the UI TODO - agreed but let's take it out of the BIP and maybe make it an alternative document. Or just replace it with a recommendation that "the user interface should be designed to ensure users understand the difference between an unsigned and signed payment request, for best practices see <here>" serialized_paymentrequest -> serialized_payment_request? Otherwise languages that use CamelCase will look odd .... setSerializedPaymentrequest() The question of root CAs still needs resolution. I stick with my recommendation to support all CAs that browsers support. Obviously, it's better for a merchant to obtain an EV cert than a domain verification cert - the UI can reflect the higher level of verification. I doubt there's a need to specify a max number of certs in a chain. But if you want to, go for something high, like 256. There's no point in trying to put DoS mitigations into something like this, for the same reason HTML doesn't impose a maximum page size. It's in the message builders interest to ensure it gets read by all users. Crashing their clients doesn't achieve anything as long as the crash isn't exploitable. On Fri, Dec 7, 2012 at 11:45 AM, Mike Hearn <m...@plan99.net> wrote: >> OK. I want to keep the signature field required, though, so how about: >> >> signature: digital signature over a protocol buffer serialized variation of >> the SignedPaymentRequest message where signature is a zero-byte array and >> fields are serialized in numerical order (all current protocol buffer >> implementations serialize fields in numerical order), using the public key >> in pki_data. > > Looks good to me. ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
