rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 Original date posted:2015-06-19 📝 Original message:On Fri, Jun 19, 2015 at 07:30:17AM -0700, Adrian Macneil wrote: > > 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. Unless you're sybil attacking the network and miners, consuming valuable resources and creating systemic risks of failure like we saw with Chainalysis, I don't see how you're getting "very small" double-spend probabilities. You realise how the fact that F2Pool is using full-RBF right now does strongly suggest that the chances of a double-spend are not only low, but more importantly, vary greatly? Any small change in relaying policy or even network conditions creates opportunities to double-spend. > 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). You know, you're creating an interesting bit of game theory here: if I'm a miner who doesn't already have a mining contract, why not implement full-RBF to force Coinbase to offer me one? One reason might be because other miners with such a contract - a majority - are going to be asked by Coinbase to reorg you out of the blockchain, but then we have a situation where a single entity has control of the blockchain. For the good of Bitcoin, and your own company, you'd do well to firmly state that under no condition will Coinbase ever enter into mining contracts. -- 'peter'[:-1]@petertodd.org 00000000000000000fe727215265d9ddacb2930ad2d45920b71920b7aed687f1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 650 bytes Desc: Digital signature URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150619/8c3576b9/attachment.sig>