<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:13px">I'm not sure this is actually important or useful; trusting someone not to double spend is a pretty binary thing</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><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><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Since you can detect when a double spend happens, the entire instant provider list could be automatically generated based on a 3rd party network that shares information between vendors and also monitors double spends. In that scenario, there is no hand written exclusive list of accepted instant providers. There is just a database of past history on all instant providers. That database can be used to give a confidence score for a specific instant provider for a given transaction amount. In this scenario, a new wallet company would be able to earn trust over time. If the list is made by hand, "Bitpay accepts Circle, Coinbase, and GreenAddress for instant transactions", then new wallet providers have to go around bribing Bitpay and the other large merchant transaction providers to get on their instant provider list.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Allowing more than one instant signature on a transaction is supposed to help avoid that scenario. For example, lets say I want to establish my own instant signature. I use a wallet that already has an accepted instant signature, but it also allows me to add my own instant signature. I do this so that I can start establishing trust in my own instant signature while relying on their instant signature.</font></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 18, 2014 at 6:25 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"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">- allowing multiple signatures ?</blockquote><div><br>
</div>
<div>I'm not sure this is actually important or useful; trusting someone not to double spend is a pretty binary thing. I'm not sure saying "you need to get three independent parties to sign off on this" is worth the hassle, especially because the first signature is obvious (your risk analysis provider or hardware) but the second and third are ..... who? Special purpose services you have to sign up for? Seems like a hassle.</div>
<div><br></div><div>But it's up to you.</div></div></div></div>
<br>------------------------------------------------------------------------------<br>
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions<br>
Find What Matters Most in Your Big Data with HPCC Systems<br>
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.<br>
Leverages Graph Analysis for Fast Processing & Easy Data Exploration<br>
<a href="http://p.sf.net/sfu/hpccsystems" target="_blank">http://p.sf.net/sfu/hpccsystems</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><br></div></div>