> On Jun 21, 2015, at 1:41 AM, Btc Drak <btcd...@gmail.com> wrote:
> Eric,
> BitPay clearly do understand the risks of 0-conf. In case you were not aware 
> BitPay does not particularly "accept zero confirm transactions". When a 
> payment is seen on the network the payment screen reports the invoice has 
> been paid, but that's front-end user facing. On the back end it's marked as 
> paid but the API exposes the the confirmation status allowing the merchant to 
> make business decisions about when to progress to fulfilment. A good example 
> of this is Neteller (a sort of paypal variant) which allows one to fund the 
> account with fiat using Bitcoin, via Bitpay. When you pay the bitpay invoice, 
> your account is marked as payment pending until there are some confirmations.

I am glad to hear that. Yes, it absolutely makes sense to let the merchant to 
make business decisions still pending confirmation (i.e. should I actually 

> Coinbase does not expose the confirmation status and from what I understand 
> (not checked myself) they guarantee payment to merchants for 0-confirm, 
> regardless of whether they confirm or not.

Then Coinbase is essentially taking on the role of an insurer…are they taking 
the appropriate precautions to limit potential losses? Can they make up for 
these losses with fees? And if not (or if they don’t really have a quantifiable 
risk model) could they survive a worst-case scenario with at most a surface 
wound? (i.e. a systemic attack involving many machines in many different places 
all attacking at once).

It would be absolutely the height of idiocy to guarantee payment on merchandise 
that has yet to ship, i.e. So I hope these reports are wrong :)

- Eric Lombrozo

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

Bitcoin-development mailing list

Reply via email to