> 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 alw
On Fri, Dec 7, 2012 at 6:01 AM, Mike Hearn 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 implementation
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
> 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 buffe
4 matches
Mail list logo
