Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2012-12-07 📝 Original message:> yeah... I had similar ...
📅 Original date posted:2012-12-07
📝 Original message:> 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
have the option of just adding a single output and being done with it.
But in future they'll probably want to keep their income in unlinkable
chunks of a size that's up to them, and multi-outputs are needed for
this (the idea being, the users wallet tries to keep a
close-as-possible match between the requested outputs and their own).
OK, let's punt on tipping for now.
> If a bitcoin client accepts unsigned payment requests (a couple of people
> have asked if that would be possible so I think that is desired), then it
> doesn't have the payer's identity-- all it has is the Outputs that will be
> paid.
I see. If I were to implement a wallet I'd just display nothing
(except the size of the request). Showing an address doesn't really
help the user in any way.
> I still like the idea of only including the root CAs who have jumped through
> the hoops needed to get the "allowed to issue EV certs" blessing.
The hoops only actually apply for EV certs though, they aren't
required to do that verification for DV certs.
The main reason to use the browser root CAs is that merchants are
guaranteed to be able to re-use their existing certs. Otherwise they
might have to buy new ones, which would be annoying.
📝 Original message:> 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
have the option of just adding a single output and being done with it.
But in future they'll probably want to keep their income in unlinkable
chunks of a size that's up to them, and multi-outputs are needed for
this (the idea being, the users wallet tries to keep a
close-as-possible match between the requested outputs and their own).
OK, let's punt on tipping for now.
> If a bitcoin client accepts unsigned payment requests (a couple of people
> have asked if that would be possible so I think that is desired), then it
> doesn't have the payer's identity-- all it has is the Outputs that will be
> paid.
I see. If I were to implement a wallet I'd just display nothing
(except the size of the request). Showing an address doesn't really
help the user in any way.
> I still like the idea of only including the root CAs who have jumped through
> the hoops needed to get the "allowed to issue EV certs" blessing.
The hoops only actually apply for EV certs though, they aren't
required to do that verification for DV certs.
The main reason to use the browser root CAs is that merchants are
guaranteed to be able to re-use their existing certs. Otherwise they
might have to buy new ones, which would be annoying.