{"type":"rich","version":"1.0","author_name":"npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed","author_url":"https://nostr.ae/npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-21\n📝 Original message:Eric,\n\nBitPay clearly do understand the risks of 0-conf. In case you were not\naware BitPay does not particularly \"accept zero confirm transactions\". When\na payment is seen on the network the payment screen reports the invoice has\nbeen paid, but that's front-end user facing. On the back end it's marked as\npaid but the API exposes the the confirmation status allowing the merchant\nto make business decisions about when to progress to fulfilment. A good\nexample of this is Neteller (a sort of paypal variant) which allows one to\nfund the account with fiat using Bitcoin, via Bitpay. When you pay the\nbitpay invoice, your account is marked as payment pending until there are\nsome confirmations.\n\nCoinbase does not expose the confirmation status and from what I understand\n(not checked myself) they guarantee payment to merchants for 0-confirm,\nregardless of whether they confirm or not.\n\nI want to address something stated by Justus, that signing a payment\nmessage and broadcasting somehow solidifies intent and going back on that\nwould be fraud. This seriously conflates cryptographic certainty with human\nbehaviour. For one, humans make mistakes all the time. We get tired, we get\ndistracted, we make copy paste errors. It's entirely possible on sends a\npayment only to find it's been sent to the wrong address or the wrong\namount has been sent or the fee is wrong. Software may also misbehave\n(Electrum for example has a weird UI glitch with fees where the specified\nfee can be overwritten). r/bitcoin it littered with sad examples. What\nECDSA signing tells is that it was signed by your private key, but nothing\nelse. It does not say if *you* signed it, or that the message you signed\nwas correct.\n\n\nOn Sun, Jun 21, 2015 at 8:42 AM, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\n\u003e\n\u003e On Jun 20, 2015, at 11:45 PM, Jeff Garzik \u003cjgarzik at bitpay.com\u003e wrote:\n\u003e\n\u003e On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo \u003celombrozo at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e  but we NEED to be applying some kind of pressure on the merchant end to\n\u003e\u003e upgrade their stuff to be more resilient\n\u003e\u003e\n\u003e\n\u003e Can you be specific?  What precise technical steps would you have BitPay\n\u003e and Coinbase do?  We upgrade our stuff to... what exactly?\n\u003e\n\u003e --\n\u003e Jeff Garzik\n\u003e Bitcoin core developer and open source evangelist\n\u003e BitPay, Inc.      https://bitpay.com/\n\u003e\n\u003e\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 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 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\u003e\n\u003e As for software tools to accomplish these things, we can talk about that\n\u003e offline :)\n\u003e\n\u003e\n\u003e - Eric Lombrozo\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150621/4abdd8ca/attachment.html\u003e"}