Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.108 as permitted sender)
	client-ip=62.13.148.108; envelope-from=pete@petertodd.org;
	helo=outmail148108.authsmtp.net; 
Date: Fri, 19 Jun 2015 12:37:46 -0400
From: Peter Todd <pete@petertodd.org>
To: Adrian Macneil <adrian@coinbase.com>
Message-ID: <20150619163745.GA26347@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>
	<20150619140815.GA32470@savin.petertodd.org>
	<CAMK47c9NhX2gzCioTycEPXqyYeKRM9XgXuW9MGyj=OdGsKVbFg@mail.gmail.com>
	<20150619145940.GB5695@savin.petertodd.org>
	<CAMK47c8Mc8v2C4aG=7GdAQ7ZCR2qXhfq-dktNS7bDa00RdKThw@mail.gmail.com>
	<20150619154054.GA13498@savin.petertodd.org>
	<CAMK47c84w=2c9y8MKHTzFf05DmKXz74a=iFViA-oZ1uRDZCAWg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G"
Content-Disposition: inline
In-Reply-To: <CAMK47c84w=2c9y8MKHTzFf05DmKXz74a=iFViA-oZ1uRDZCAWg@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


--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 19, 2015 at 09:18:54AM -0700, Adrian Macneil wrote:
> >
> > > So connecting to many nodes just because we can and it's not technica=
lly
> > > prevented is bad for the network and creating systemic risks of failu=
re,
> >
> > Well it is actually; that's why myself, Wladimir van der Laan, and
> > Gregory Maxwell all specifically=B9 called Chainalysis's actions a sybil
> > attack.
> >
> > The Bitcoin P2P network is resilliant to failure when the chance of any
> > one node going down is uncorrelated with others. For instance if you
> > accidentally introduced a bug in your nodes that failed to relay
> > transactions/blocks properly, you'd simultaneously be disrupting a large
> > portion of the network all at once.
> >
>=20
> This is exactly what your RBF patch is doing. By your own logic, nodes on
> the network should be allowed to relay (or not relay) whatever they wish.

Ah, seems you misunderstand the problem.

By properly we're concerned that things do get relayed, not that they do
not. In particularl with blocks a fairly to relay valid blocks will
quickly lead to a loss of consensus.

> > How many nodes is Coinbase connecting too? What software are they
> > running? What subnets are they using? In particular, are they all on one
> > subnet or multiple?
> >
>=20
> We're running about a dozen nodes running regular Bitcoin Core in various
> subnets. We aren't doing anything particularly out of the ordinary here.
> Nothing that would fall under your definition of a sybil attack or harmful
> to the network.

Right, so those dozen nodes, how many outgoing connections are they
making?

> > But of course, you'd never 51% the network right? After all it's not
> > possible to guarantee that your miner won't mine double-spends, as there
> > is no single consensus definition of which transaction came first, nor
> > can there be.
> >
> > Or do you see things differently? If I'm a small miner should I be
> > worried my blocks might be rejected by the majority with hashing power
> > contracts because I'm unable to predict which transactions Coinbase
> > believes should go in the blockchain?
> >
>=20
> You seem so concerned that we are actively trying to harm or control the
> network. We're simply trying to drive bitcoin adoption by making it easy
> for people to spend their bitcoin with merchants online. The problems we
> face are no different from other merchant processors, or small independent
> merchants accepting online or point-of-sale payments.
>
> We've historically had relatively little interest in what miners were doi=
ng
> (until RBF came out) - for the most part it didn't affect our business.
> However, most large merchants would be simply uninterested in accepting
> bitcoin if we forced their customers to wait 10-60 minutes for their
> payments to confirm. Many have inventory management systems which can not
> even place items on hold that long.

While your goals may be reasonable, again, the question is how are you
going to achieve them? Do you accept that you may be in a position where
you can't guarantee confirmations? Again, what's your plan to deal with
this? For instance, I know Coinbase is contractually obliged to accept
zeroconf payments with at least some of your customers - how strong are
those agreements?

What we're worried about is your plan appears to include nothing
concrete beyond the possibility of getting contracts with hashing power,
maybe even just a majority of hashing power. This is something that
should concern everyone in the Bitcoin ecosystem, and it'd help if you
clearly stated what your intentions are.

--=20
'peter'[:-1]@petertodd.org
00000000000000001128683847671e0ca022f9c74df90a3dc718545379101b72

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

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

iQGrBAEBCACVBQJVhEVWXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwOTlmZmQzOTc5MDRhMGFkNzEwYzVhZDI3YWU5ZGZiZjg3
NTY4Y2ExMzI5MWEyNzcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfs9hggAiZnB4i7zOilQnOKpEogIPq+t
lzshbYlZJhSo+j5J+pwFiijXABJVZXin6RnVXpim6l1TV27F5fVSInVAgSIr29oH
KTy2/uwZIDuFyrwo0HWL9Nz3bkVMnwsnswAt5JQRjmoAKPZSyr37BYE4idxfjtwT
zAll/XHo2WPUMemLBnEYTAhnU2vja++IBvgywSeceVQIde0TmcY+zfuSLNZYC9ZX
FVPJ0J0Rzctqf/Tj2/wmszJ7LvE6ewDyaopoL5AyUcpo4g5OASLNhSX6MzLjoNtY
3/I2CQjhoSZeLO9lmRPJ4Q0yherhL4dKZAnCHuKQOBz1rUJgjdmTrGrMp1ZEbA==
=OWBL
-----END PGP SIGNATURE-----

--k1lZvvs/B4yU6o8G--