Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]