Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.75 as permitted sender)
	client-ip=62.13.149.75; envelope-from=pete@petertodd.org;
	helo=outmail149075.authsmtp.net; 
Date: Fri, 19 Jun 2015 10:08:15 -0400
From: Peter Todd <pete@petertodd.org>
To: Adrian Macneil <adrian@coinbase.com>
Message-ID: <20150619140815.GA32470@savin.petertodd.org>
References: <20150619103959.GA32315@savin.petertodd.org>
	<CABsx9T1pnT=Tty3+tg+EUphLwQrWXf9EEwUOGuyNcdu=4wAqTg@mail.gmail.com>
	<20150619135245.GB28875@savin.petertodd.org>
	<CAMK47c_kCgb6hEUf_JePAC_tBK8aCF1W4f1guiAah-Gj_cFfSw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6"
Content-Disposition: inline
In-Reply-To: <CAMK47c_kCgb6hEUf_JePAC_tBK8aCF1W4f1guiAah-Gj_cFfSw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Precedence: list


--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 19, 2015 at 07:00:56AM -0700, Adrian Macneil wrote:
> >
> > For instance, if Coinbase had
> > contracts with 80% of the Bitcoin hashing power to guarantee their
> > transactions would get mined, but 20% of the hashing power didn't sign
> > up, then the only way to guarantee their transactions could be for the
> > 80% to not build on blocks containing doublespends by the 20%.
> >
>=20
> This seems to be more of a problem with centralized mining than zeroconf
> transactions.

You're mistaking cause and effect: the contracts will drive
centralization of mining, as only the larger, non-anonymous, players
have the ability to enter into such contracts.

> Speaking of, could we get a confirmation that Coinbase is, or is not,
> > one of the merchant service providers trying to get hashing power
> > contracts with mining pools for guaranteed transaction acceptance? IIRC
> > you are still an advisor to them. This is a serious concern for the
> > reasons I outlined in my post.
> >
>=20
> We have no contracts in place or plans to do this that I am aware of.
>=20
> 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?

--=20
'peter'[:-1]@petertodd.org
000000000000000005a4c76d0bf088ef3e059914d6fc0335683a92b5be01b7dc

--IJpNTDwzlM2Ie8A6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVhCJKXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMjFlMjg1MGM4NmE5OWM4NjcyYzkzOTZhZGViYjBhMDc1
OWU4NWE1ZmJiODkyMmMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfv6rwgAjIzRTRljEa55+DCJ2tDNcj8H
2jAr9zLlm4g0QhFlwI4ZYp5ryqiB+CJWiXs2LEgDSwbGnPcWRPM2RDCPyr9J0G4x
NAdpGgrN22lR/BFThnNqOrVktMW0FTYba3bhDEiMpGX5+aAoKnqZHsojR5uuLzgl
c4+OS/DVsPjrJ/oXxKPeaGnMqVbrRJUftFGmXTObF9LmZIRP7l38Yc5FbwQ9bMMQ
XcmL0hWOmWwcEJ/RQX1gIkaPQh24UxFc/ryJX0BPl5NW5+qLuw+rCTf3H/CrNsLL
+Pma+jDJlQNLUa9SBvj1DlEzi7mqpmTkk5JDSvdRitAV0AH5A4U/PJQi8WgRAg==
=+bMm
-----END PGP SIGNATURE-----

--IJpNTDwzlM2Ie8A6--