rich1.0npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uhttps://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0unjumphttps://nostr.ae📅 Original date posted:2015-06-19 📝 Original message: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> 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 > 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/c2719e0f/attachment.html>