Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-06-18 📝 Original message:> > I think that's true if ...
📅 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>;
📝 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>;