Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2012-12-07 📝 Original message:Yet more comments (I guess ...
📅 Original date posted:2012-12-07
📝 Original message: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 <mike at 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.
📝 Original message: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 <mike at 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.