Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-20 📝 Original message:It all comes down to ...

📅 Original date posted:2015-06-20
📝 Original message:It all comes down to managing risk. If you’ve got a decent risk model with capped losses and safe recovery mechanisms…and it’s still profitable…it’s fine. But most payment processors and merchants right now probably don’t have particularly good risk models and are making many dangerous assumptions…and probably would not be able to gracefully handle very many risk scenarios.

- Eric Lombrozo


> On Jun 19, 2015, at 6:23 PM, Aaron Voisine <voisine at gmail.com> wrote:
>
> > What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe.
>
> They don't need to be made cryptographically safe, they just have to be safer than, for instance, credit card payments that can be charged back. As long as it's reasonably good in practice, that's fine.
>
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com <http://breadwallet.com/>;
> On Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach <mark at friedenbach.org <mailto:mark at friedenbach.org>> wrote:
> What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe.
>
> On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson <andreas at petersson.at <mailto:andreas at petersson.at>> wrote:
> I have some experience here. If you are seriously suggesting these
> measures, you might as well kill retail transactions altogether.
>
> In practice, if a retail place starts to accept bitcoin they have a
> similar situation as with cash, only that the fraud potential is much
> lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
> and the fraud frequency is also much lower.
>
> 0-conf concerns were never a problem in practice. except for 2-way atms
> i have never heard of a problem that was caused by double spends.
> while adding these measures is generally positive, requiring them means
> excluding 99.9% of the potential users. so you might as well not do it.
>
> RBF as implemented by F2Pool just flat out lowers Bitcoins utility
> value. So it's a bad thing.
>
> for any online or automated system, waiting for a handful of
> confirmations was always recommended practice.
>
> Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
> > Retail POS merchants probably should not be accepting vanilla Bitcoin
> > payments, as Bitcoin alone does not (and cannot) guarantee the
> > irreversibility of a transaction until it has been buried several
> > blocks deep in the chain. Retail merchants should be requiring a
> > co-signature from a mutually trusted co-signer that vows never to sign
> > a double-spend.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>;
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>;
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/21052728/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/21052728/attachment.sig>;