>
> 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.
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
