{"type":"rich","version":"1.0","author_name":"npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","author_url":"https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-21\n📝 Original message:On Sun, Jun 21, 2015 at 12:42 AM, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\n\u003e Thanks for asking *the* question, Jeff. We often get caught up in these\n\u003e philosophical debates…but at the end of the day we need something concrete.\n\u003e\n\u003e Even more important than the specific software you’re using is the\n\u003e security policy.\n\u003e\n\u003e If you must accept zero confirmation transactions, there are a few\n\u003e concrete things you can do to reduce your exposure:\n\u003e\n\u003e 1) limit the transaction amounts for zero confirmation transactions - do\n\u003e not accept them for very high priced goods…especially if they require\n\u003e physical shipping.\n\u003e 2) limit the total amount of unconfirmed revenue you’ll tolerate at any\n\u003e given moment - if the amount is exceeded, require confirmations.\n\u003e 3) give merchants of subscription services (i.e. servers, hosting, etc…)\n\u003e the ability to shut the user out if a double-spend is detected.\n\u003e\n\nAlready done -- BitPay merchants choose their level of transaction\nsecurity.  Level of confirmations is directly exposed to merchants, so that\nthey choose the level of risk for themselves.\n\nPhysically shipped orders and subscriptions are actually the easy cases and\nare already handled.  These can accept 0-conf for an initial order phase,\nthen have the luxury of time to wait for confirmations before shipping /\ncanceling a subscription.\n\nElectronic goods instantly delivered are the toughest use case.  Even\nthere, merchants choose their level of risk.\n\n\n\n\u003e 4) collect legal information on purchasers (or have the merchants collect\n\u003e this information) so you have someone to go after if they try to screw you\n\u003e\n\nThe system requests this information on orders yes.  Merchants also collect\nthis info as their needs dictate.\n\n\n\n\u003e 5) create a risk profile for users…and flag suspicious behavior (i.e.\n\u003e someone trying to purchase a bunch of stuff that totally doesn’t fit into\n\u003e their purchasing habits).\n\u003e 6) get insurance (although right now reasonably-priced insurance is\n\u003e probably pretty hard to obtain since statistics are generally of little\n\u003e use…we’re entering uncharted territory).\n\u003e 7) set up a warning system and a “panic” button so that if you start to\n\u003e see an attack you can immediately disable all zero confirmation\n\u003e transactions system-wide.\n\u003e 8) independently verify all inbound transactions and connect to multiple\n\u003e network nodes…check them against one another.\n\u003e\n\nDefinitely looking at or have implemented this sort of stuff.  I cannot get\ninto detail in public...\n\n-- \nJeff Garzik\nBitcoin core developer and open source evangelist\nBitPay, Inc.      https://bitpay.com/\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/8d925c35/attachment.html\u003e"}