> Supporting it in the protocol is easy. Building such a thing: that's hard. Decentralised automated reputation systems are complex and subtle.

Bitcoin is valuable as a protocol because it is truly decentralized. The complexity involved in building this system was expansive, but I think we can all agree it was worth the trouble. With this particular topic of instant transactions it seems we have to be very careful about pushing Bitcoin in a centralized direction for the sake of a simple quick solution. Building an automated system to solve the instant transaction problem will be difficult, but also well worth the effort, and exactly like you're saying Mike, I just want to make sure the door is left open protocol wise for a robust solution in the future.

On Wed, Jun 18, 2014 at 9:09 AM, Mike Hearn <mike@plan99.net> wrote:

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.