<div dir="ltr"><div>If you&#39;re hoping the instant providers list won&#39;t need to scale then you&#39;re essentially saying that we need a solution to the double spend problem. That is a good point. Double spends are one of the biggest issues remaining in the protocol. I&#39;ve seen so many people talk about bad experiences trying to spend Bitcoin at a restaurant and waiting an hour for confirmations. This entire BIP extension is a band aid for double spends. If double spends are not resolved, there will be a million instant providers in the long run and if double spends are resolved then this BIP extension is completely unnecessary. Is solving doublespends off the table?</div>
<div><br></div><div>What if we solved doublespends like this: If a node receives 2 transactions that use the same input, they can put both of them into the new block as a proof of double spend, but the bitcoins are not sent to the outputs of either transactions. They are instead treated like a fee and given to the block solver node. This gives miners the needed incentive and tools to end doublespends instead of being forced to favor one transaction over the other.</div>
<div><br></div><div>I will write up a BIP if this seems like a practical approach.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 16, 2014 at 5:19 AM, Mike Hearn <span dir="ltr">&lt;<a href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>&gt;</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">Looking good! I think this is much better than the original draft. Agree with Andreas that supports_instant is simply equal to (supported_instant_providers.size() &gt; 1) which makes it redundant.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Daniel is right that putting every possible provider in the Payment message might not scale in a world where there are huge numbers of instant-confirmation providers, but I&#39;m hoping that we never have to scale to that size, because if we did that&#39;d rather imply that Bitcoin has become useless for in-person payments without trusted third parties and avoiding that is rather the whole point of the project :) So I&#39;m OK with some theoretical lack of scalability for now. </div>

<div class="gmail_extra"><br></div><div class="gmail_extra">A more scalable approach would be for the user to send the name and signature of their &quot;instant provider&quot; every time and the merchant just chooses whether to ignore it or not, but as Lawrence points out, this is incompatible with the provider charging extra fees for &quot;instantness&quot;. But should we care? I&#39;m trying to imagine what the purchasing experience is like with optional paid-for third party anti-double-spend protection. Ultimately it&#39;s the merchant who cares about this, not me, so why would I ever pay? It makes no sense for me to pay for double spend protection for the merchant: after all, I&#39;m honest. This is why it doesn&#39;t make sense for me to pay miners fees either, it&#39;s the <i>receiver</i> who cares about confirmations, not the sender.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">So I wonder if a smarter design is that the user always submits the details of their instantness provider and we just don&#39;t allow for optional selection of instantness. I&#39;m not sure that works, UX wise, so is having a less scalable design to support it worthwhile?</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 &amp; 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>