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
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
On Fri, Dec 7, 2012 at 6:01 AM, Mike Hearn m...@plan99.net wrote:
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).
Yes, my next step is prototyping.
Note that this is not a BIP yet: I want to have a working
yeah... I had similar thoughts on what to do if some Outputs specify an
amount and others don't. I'm still waffling on whether or not I like
allowing repeated Outputs; a single Output would make the spec a fair bit
simpler
Yes, but at the cost of privacy. Generators of payment requests always
4 matches
Mail list logo
