> On Jun 21, 2015, at 12:42 AM, Eric Lombrozo <elombr...@gmail.com> wrote:
> 
> 
>> On Jun 20, 2015, at 11:45 PM, Jeff Garzik <jgar...@bitpay.com 
>> <mailto:jgar...@bitpay.com>> wrote:
>> 
>> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombr...@gmail.com 
>> <mailto:elombr...@gmail.com>> wrote:
>>  but we NEED to be applying some kind of pressure on the merchant end to 
>> upgrade their stuff to be more resilient
>> 
>> Can you be specific?  What precise technical steps would you have BitPay and 
>> Coinbase do?  We upgrade our stuff to... what exactly?
>> 
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc.      https://bitpay.com/ <https://bitpay.com/>
> 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.
> 
> Even more important than the specific software you’re using is the security 
> policy.
> 
> If you must accept zero confirmation transactions, there are a few concrete 
> things you can do to reduce your exposure:
> 
> 1) limit the transaction amounts for zero confirmation transactions - do not 
> accept them for very high priced goods…especially if they require physical 
> shipping.
> 2) limit the total amount of unconfirmed revenue you’ll tolerate at any given 
> moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc…) the 
> ability to shut the user out if a double-spend is detected.
> 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
> 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).
> 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).
> 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.
> 8) independently verify all inbound transactions and connect to multiple 
> network nodes…check them against one another.
> 
> 
> As for software tools to accomplish these things, we can talk about that 
> offline :)
> 
> 
> - Eric Lombrozo
> 
> 
> 
> 

I should also point out that pretty much all of these suggestions (except for 
maybe 8) would apply to ANY payment system…they are NOT specific to Bitcoin 
whatsoever. Any serious payment processor should have these sorts of policies 
engrained as part of company culture…or else one day (probably not too long 
from now) you’ll be out of business. The mere suggestion that changing relay 
policy would pose significant threats to the bottom line of a payment processor 
is about the height of amateurishness, IMHO.


- Eric Lombrozo

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Reply via email to