📅 Original date posted:2014-06-18
📝 Original message:>
> I think that's true if you assume that the instant provider list is based
> on a by hand created list of accepted instant providers. That's how VISA
> works now and that's why I was asking for an approach where the
> trusted_instant_providers list is scalable because that seems very
> dangerous.
>
Supporting it in the protocol is easy. Building such a thing: that's hard.
Decentralised automated reputation systems are complex and subtle.
I don't feel strongly about whether the field should be "optional" or
"repeated", 100% of implementations in the forseeable future would just
look at the first item and ignore the rest. But if later someone did crack
this problem it would lead to a simple upgrade path. So perhaps you're
right and the protobuf should allow multiple signatures. It means a new
sub-message to wrap the pki_type, pki_data and signature fields into one,
and then making that repeated.
Up to Lawrence.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140618/cc609821/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:22:42
in reply to nevent1q…hpzg
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:22:42Event JSON
{
"id": "67458821e26a5d7bafc58184d8a2cd287aad61aaa267eb6d312748c5362f6545",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686151362,
"kind": 1,
"tags": [
[
"e",
"ed0eede28e160c2ef8ddd5af1ee3069fdb0eb5f4c939c1c09a1a5f338c30c628",
"",
"root"
],
[
"e",
"1644e3bad342143b117c966ad199586f2b701eabe13b8dde9186b0d227e1c847",
"",
"reply"
],
[
"p",
"dce3e74d4fb3751e07a976b4d9e0d8c9189e3758c92528fa0b2d7a507e701bb2"
]
],
"content": "📅 Original date posted:2014-06-18\n📝 Original message:\u003e\n\u003e I think that's true if you assume that the instant provider list is based\n\u003e on a by hand created list of accepted instant providers. That's how VISA\n\u003e works now and that's why I was asking for an approach where the\n\u003e trusted_instant_providers list is scalable because that seems very\n\u003e dangerous.\n\u003e\n\nSupporting it in the protocol is easy. Building such a thing: that's hard.\nDecentralised automated reputation systems are complex and subtle.\n\nI don't feel strongly about whether the field should be \"optional\" or\n\"repeated\", 100% of implementations in the forseeable future would just\nlook at the first item and ignore the rest. But if later someone did crack\nthis problem it would lead to a simple upgrade path. So perhaps you're\nright and the protobuf should allow multiple signatures. It means a new\nsub-message to wrap the pki_type, pki_data and signature fields into one,\nand then making that repeated.\n\nUp to Lawrence.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140618/cc609821/attachment.html\u003e",
"sig": "28b4430e4d5f41cd7cbbdda3f46520773069add26c8dc308200b1f2eaaab61d4059fa28e5599e940987e962475b7e39f952b2c2bea094cddf75f11174806c469"
}