rich1.0npub18plyg5mfmzwlvkcx0fhudfll3x5phjvvlglw4dgj6t5ehyp87ttqzv2ml4https://nostr.ae/npub18plyg5mfmzwlvkcx0fhudfll3x5phjvvlglw4dgj6t5ehyp87ttqzv2ml4njumphttps://nostr.ae📅 Original date posted:2015-06-19 📝 Original message:> > > We have no contracts in place or plans to do this that I am aware of. > > > > However, we do rely pretty heavily on zeroconf transactions for merchant > > processing, so if any significant portion of the mining pools started > > running your unsafe RBF patch, then we would probably need to look into > > this as a way to prevent fraud. > > What happens if the mining pools who are mining double-spends aren't > doing it delibrately? Sybil attacking pools appears to have been done > before to get double-spends though, equally there are many other changes > the reduce the reliability of transaction confirmations. For instance > the higher demands on bandwidth of a higher blocksize will inevitably > reduce the syncronicity of mempools, resulting in double-spend > opportunities. Similarly many proposals to limit mempool size allow > zeroconf double-spends. > > In that case would you enter into such contracts? > We take it as it comes. Currently, it's perfectly possible to accept zeroconf transactions with only a very small chance of double spend. As long as it's only possible to double spend a small fraction of the time, it's an acceptable cost to us in exchange for being able to provide a fast checkout experience to customers and merchants. If the status quo changes, then we will need to investigate alternatives (which realistically would include mining contracts, or only accepting instant payments from other trusted hosted wallets, which would be a net loss for decentralization). Long term we would prefer to see an open, decentralized solution, such as payment channels / green addresses / lightening networks. However, I think as a community we are a long way away from choosing a standard here and implementing it across all popular wallet software and merchant processors. Adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/e0ee9118/attachment.html>