📅 Original date posted:2014-07-28
📝 Original message:On Mon, Jul 28, 2014 at 11:01 AM, Mark van Cuijk <mark at coinqy.com> wrote:
> Good to see that it has been discussed, but I see the idea has been
> postponed.
>
I'm not sure postponed is the right word. It wasn't in v1, but many useful
things weren't. It's more like, a bunch of people have to do work to
upgrade this and at the moment they're all busy with other things.
> I do like the idea coined by Mike that a PP can issue non-SSL certificates
> for the purpose of merchant identification, as long as a customer is free
> to determine whether he trusts the PP for this purpose.
>
I don't think I proposed this exactly? It's the other way around - a
merchant issues an extension cert to allow the PP to act on their behalf.
> Regarding the choice of how to authenticate the PP, I’m a bit
> undetermined. Disregarding backward compatibility, I think the extended
> certificate system proposed by Mike is cleaner. However, I don’t like the
> concept of requiring two separate signatures for old and new clients.
> Taking backward compatibility in mind, I tend to prefer my proposal.
>
I'm not sure I understand. Your proposal also has two signatures. Indeed it
must because delegation of authority requires a signature, but old clients
won't understand it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140728/b00e8a15/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:24:27
in reply to nevent1q…x9ce
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:24:27Event JSON
{
"id": "eac23d1552c46b8c44b10a0560421867a2fbd6e9bdc1720811ce0972a76dceae",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686151467,
"kind": 1,
"tags": [
[
"e",
"a3583fd779ae01bcb2bc77268993e943631589c36653a53f89e3320d68ba00ed",
"",
"root"
],
[
"e",
"0dec9502c25a832bdf46a08cb85502d9ff363c0d054fbb3ec67fc54aba629ec9",
"",
"reply"
],
[
"p",
"8fd2b087c87885a0caec95c00fdbb48e63439b0bb5715488745108e5d300bd98"
]
],
"content": "📅 Original date posted:2014-07-28\n📝 Original message:On Mon, Jul 28, 2014 at 11:01 AM, Mark van Cuijk \u003cmark at coinqy.com\u003e wrote:\n\n\u003e Good to see that it has been discussed, but I see the idea has been\n\u003e postponed.\n\u003e\n\nI'm not sure postponed is the right word. It wasn't in v1, but many useful\nthings weren't. It's more like, a bunch of people have to do work to\nupgrade this and at the moment they're all busy with other things.\n\n\n\u003e I do like the idea coined by Mike that a PP can issue non-SSL certificates\n\u003e for the purpose of merchant identification, as long as a customer is free\n\u003e to determine whether he trusts the PP for this purpose.\n\u003e\n\nI don't think I proposed this exactly? It's the other way around - a\nmerchant issues an extension cert to allow the PP to act on their behalf.\n\n\n\u003e Regarding the choice of how to authenticate the PP, I’m a bit\n\u003e undetermined. Disregarding backward compatibility, I think the extended\n\u003e certificate system proposed by Mike is cleaner. However, I don’t like the\n\u003e concept of requiring two separate signatures for old and new clients.\n\u003e Taking backward compatibility in mind, I tend to prefer my proposal.\n\u003e\n\nI'm not sure I understand. Your proposal also has two signatures. Indeed it\nmust because delegation of authority requires a signature, but old clients\nwon't understand it.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140728/b00e8a15/attachment.html\u003e",
"sig": "7dd6398373d29b1a831c7d0de0cac7159a2e43bbb58b04098235b5a2b6168a1cfe65ee0cc5842a68b722350ca650804db90de8b4989d9a02c3cbfcbacdc14a4b"
}