<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:13px">Supporting it in the protocol is easy. Building such a thing: that's hard. Decentralised automated reputation systems are complex and subtle. </span><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">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.</font></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 18, 2014 at 9:09 AM, Mike Hearn <span dir="ltr"><<a href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><font face="arial, sans-serif">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.</font></div>
</div></blockquote><div><br></div></div><div>Supporting it in the protocol is easy. Building such a thing: that's hard. Decentralised automated reputation systems are complex and subtle. </div><div><br></div><div>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.</div>
<div><br></div><div>Up to Lawrence.</div></div></div></div>
</blockquote></div><br></div>