Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Eric Lombrozo <elombrozo@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]


> On Jun 21, 2015, at 1:41 AM, Btc Drak <btcdrak@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 ship?)

> 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 #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]