<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 20, 2015, at 11:45 PM, Jeff Garzik &lt;<a href="mailto:jgarzik@bitpay.com" class="">jgarzik@bitpay.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <span dir="ltr" class="">&lt;<a href="mailto:elombrozo@gmail.com" target="_blank" class="">elombrozo@gmail.com</a>&gt;</span> wrote:<br class=""><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">&nbsp;but we NEED to be applying some kind of pressure on the merchant end to upgrade their stuff to be more resilient<br class=""></blockquote><div class=""><br class=""></div><div class="">Can you be specific?&nbsp; What precise technical steps would you have BitPay and Coinbase do?&nbsp; We upgrade our stuff to... what exactly?</div></div><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature">Jeff Garzik<br class="">Bitcoin core developer and open source evangelist<br class="">BitPay, Inc. &nbsp; &nbsp; &nbsp;<a href="https://bitpay.com/" target="_blank" class="">https://bitpay.com/</a></div>
</div></div>
</div></blockquote></div><br class=""><div class="">Thanks for asking *the* question, Jeff. We often get caught up in these philosophical debates…but at the end of the day we need something concrete.</div><div class=""><br class=""></div><div class="">Even more important than the specific software you’re using is the security policy.</div><div class=""><br class=""></div><div class="">If you must accept zero confirmation transactions, there are a few concrete things you can do to reduce your exposure:</div><div class=""><br class=""></div><div class="">1) limit the transaction amounts for zero confirmation transactions - do not accept them for very high priced goods…especially if they require physical shipping.</div><div class="">2) limit the total amount of unconfirmed revenue you’ll tolerate at any given moment - if the amount is exceeded, require confirmations.</div><div class="">3) give merchants of subscription services (i.e. servers, hosting, etc…) the ability to shut the user out if a double-spend is detected.</div><div class="">4) collect legal information on purchasers (or have the merchants collect this information) so you have someone to go after if they try to screw you</div><div class="">5) create a risk profile for users…and flag suspicious behavior (i.e. someone trying to purchase a bunch of stuff that totally doesn’t fit into their purchasing habits).</div><div class="">6) get insurance (although right now reasonably-priced insurance is probably pretty hard to obtain since statistics are generally of little use…we’re entering uncharted territory).</div><div class="">7) set up a warning system and a “panic” button so that if you start to see an attack you can immediately disable all zero confirmation transactions system-wide.</div><div class="">8) independently verify all inbound transactions and connect to multiple network nodes…check them against one another.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">As for software tools to accomplish these things, we can talk about that offline :)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">- Eric Lombrozo</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>