{"type":"rich","version":"1.0","author_name":"npub18plyg5mfmzwlvkcx0fhudfll3x5phjvvlglw4dgj6t5ehyp87ttqzv2ml4","author_url":"https://nostr.ae/npub18plyg5mfmzwlvkcx0fhudfll3x5phjvvlglw4dgj6t5ehyp87ttqzv2ml4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-19\n📝 Original message:\u003e\n\u003e \u003e We have no contracts in place or plans to do this that I am aware of.\n\u003e \u003e\n\u003e \u003e However, we do rely pretty heavily on zeroconf transactions for merchant\n\u003e \u003e processing, so if any significant portion of the mining pools started\n\u003e \u003e running your unsafe RBF patch, then we would probably need to look into\n\u003e \u003e this as a way to prevent fraud.\n\u003e\n\u003e What happens if the mining pools who are mining double-spends aren't\n\u003e doing it delibrately? Sybil attacking pools appears to have been done\n\u003e before to get double-spends though, equally there are many other changes\n\u003e the reduce the reliability of transaction confirmations. For instance\n\u003e the higher demands on bandwidth of a higher blocksize will inevitably\n\u003e reduce the syncronicity of mempools, resulting in double-spend\n\u003e opportunities. Similarly many proposals to limit mempool size allow\n\u003e zeroconf double-spends.\n\u003e\n\u003e In that case would you enter into such contracts?\n\u003e\n\nWe take it as it comes.\n\nCurrently, it's perfectly possible to accept zeroconf transactions with\nonly a very small chance of double spend. As long as it's only possible to\ndouble spend a small fraction of the time, it's an acceptable cost to us in\nexchange for being able to provide a fast checkout experience to customers\nand merchants.\n\nIf the status quo changes, then we will need to investigate alternatives\n(which realistically would include mining contracts, or only accepting\ninstant payments from other trusted hosted wallets, which would be a net\nloss for decentralization).\n\nLong term we would prefer to see an open, decentralized solution, such as\npayment channels / green addresses / lightening networks. However, I think\nas a community we are a long way away from choosing a standard here and\nimplementing it across all popular wallet software and merchant processors.\n\nAdrian\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/e0ee9118/attachment.html\u003e"}