<div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(34,34,34);white-space:nowrap">Mike Hearn <<a href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>> wrote:</span><br>
</div><div style="font-family:arial,sans-serif;font-size:13px">>> A more scalable approach would be for the user to send the name and<br>>> signature of their "instant provider" every time and the merchant just<br>
>> chooses whether to ignore it or not, but as Lawrence points out, this is<br>>> incompatible with the provider charging extra fees for "instantness". But<br>>> should we care? I'm trying to imagine what the purchasing experience is like<br>
>> with optional paid-for third party anti-double-spend protection. Ultimately<br>>> it's the merchant who cares about this, not me, so why would I ever pay?<br><span style="color:rgb(34,34,34)"><br></span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(34,34,34);white-space:nowrap">Lawrence Nahum <<a href="mailto:lawrence@greenaddress.it" target="_blank">lawrence@greenaddress.it</a>> wrote:</span><span style="color:rgb(34,34,34)"><br>
</span></div><div style="font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(34,34,34)">> I think you are wrong here.</span><br style="color:rgb(34,34,34)"><span style="color:rgb(34,34,34)">> Just because up to date credit cards charged the merchant which in turn</span><br style="color:rgb(34,34,34)">
<span style="color:rgb(34,34,34)">> charged you and the ordinary cash payer doesn't mean a newer and better</span><br style="color:rgb(34,34,34)"><span style="color:rgb(34,34,34)">> system can't be transparent from day one.</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">I don't think a whitelist of trust is a practical approach because you are going to want to have varying levels of trust in different instant providers. This would be based on how large their past transaction volume has been. For that reason maybe another approach is an additional negotiation message between the merchant and wallet. Merchant sends payment details -> wallet responds with their instant information requesting if an instant transaction will be accepted for this transaction. Merchant weighs the risk based on historical data about this particular instant provider and the amount of the requested transaction -> Merchant responds yes or no.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">That approach avoids the scaling issue, but also allows for Lawrence's use case of charging the user a fee only in the case where the instant transaction is supported.</font></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 16, 2014 at 1:29 PM, Daniel Rice <span dir="ltr"><<a href="mailto:drice@greenmangosystems.com" target="_blank">drice@greenmangosystems.com</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>I'm trying to think through how to encourage the maximum number of instant signature providers and avoid the VISA monopoly. Ideal case would be that people can even be their own instant provider.</div>
<div><br></div>What if the protocol allowed multiple instant signatures on a transaction? Would it encourage more instant providers? For example, a new instant provider could bootstrap their own trust by paying an already trusted instant provider to co-sign the same transaction. This would be useful in the case that a new company tries to release a new wallet once the trust ring is already established. Nobody will use that wallet because it does not have the trusted history to do instant transactions, but if they can pay a small amount per transaction to a third party to cosign, they can build trust in their own signature till they can eventually have enough trust on their own. This could be how an individual user could grow trust in their own instant signature as well.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Mon, Jun 16, 2014 at 11:09 AM, Mike Hearn <span dir="ltr"><<a href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<div dir="ltr"><div>I think many of us feel it'd be better if this kind of thing were not needed at all, however, the best way to ensure it doesn't end up being used is to write code, not to try and block alternative approaches. If Bitcoin is robust the market should sort it out. If it's robust for some transactions and not others, that makes for a fun project for a future generation of hackers to sort out.</div>
<div class="gmail_extra"><br>OK, enough philosophy - let's try and keep this thread just for discussion of the BIP itself from now on. If you'd like to continue debating the Future of Bitcoin please change the subject line and break it out into a new thread.<br>
</div></div>
<br></div><div class="">------------------------------------------------------------------------------<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" target="_blank">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></div></blockquote></div><br></div>
</blockquote></div><br></div>