📅 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.
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 10:44:08
in reply to nevent1q…kj5v
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 10:44:08Event JSON
{
"id": "3d5aac2594c2f6c6c786d5a79c1707fdda7f43f0546efe181845fe9cac12a7bf",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686134648,
"kind": 1,
"tags": [
[
"e",
"1bd78b419247dfb60fa2e8b1cf4983b406411160c7aa6e19780a4034c5da34de",
"",
"root"
],
[
"e",
"570f87b8b9f5ef906d79e8eae62e1a500186c366fa6ea93026150376dcc38aff",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2012-12-07\n📝 Original message:\u003e yeah... I had similar thoughts on what to do if some Outputs specify an\n\u003e amount and others don't. I'm still waffling on whether or not I like\n\u003e allowing repeated Outputs; a single Output would make the spec a fair bit\n\u003e simpler\n\nYes, but at the cost of privacy. Generators of payment requests always\nhave the option of just adding a single output and being done with it.\nBut in future they'll probably want to keep their income in unlinkable\nchunks of a size that's up to them, and multi-outputs are needed for\nthis (the idea being, the users wallet tries to keep a\nclose-as-possible match between the requested outputs and their own).\n\nOK, let's punt on tipping for now.\n\n\u003e If a bitcoin client accepts unsigned payment requests (a couple of people\n\u003e have asked if that would be possible so I think that is desired), then it\n\u003e doesn't have the payer's identity-- all it has is the Outputs that will be\n\u003e paid.\n\nI see. If I were to implement a wallet I'd just display nothing\n(except the size of the request). Showing an address doesn't really\nhelp the user in any way.\n\n\u003e I still like the idea of only including the root CAs who have jumped through\n\u003e the hoops needed to get the \"allowed to issue EV certs\" blessing.\n\nThe hoops only actually apply for EV certs though, they aren't\nrequired to do that verification for DV certs.\n\nThe main reason to use the browser root CAs is that merchants are\nguaranteed to be able to re-use their existing certs. Otherwise they\nmight have to buy new ones, which would be annoying.",
"sig": "2bf67cf7b94fbbdb02453c2c92e285cae981508f94729ffc30d3d6ae10332d12a7e23524e5501964109cc96cf5ab4fabcca2fdd70e6b77ded98ef993e75d4376"
}