<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>