Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5zIr-00056a-Nr for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 16:38:05 +0000 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; Received: from outmail148108.authsmtp.net ([62.13.148.108]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Z5zIq-0008PV-HF for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 16:38:05 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5JGbpL8007205; Fri, 19 Jun 2015 17:37:51 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5JGbkA9015264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 19 Jun 2015 17:37:49 +0100 (BST) Date: Fri, 19 Jun 2015 12:37:46 -0400 From: Peter Todd To: Adrian Macneil Message-ID: <20150619163745.GA26347@savin.petertodd.org> References: <20150619103959.GA32315@savin.petertodd.org> <20150619135245.GB28875@savin.petertodd.org> <20150619140815.GA32470@savin.petertodd.org> <20150619145940.GB5695@savin.petertodd.org> <20150619154054.GA13498@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 85dd4c04-16a1-11e5-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwsUEkAaAgsB AmMbWlNeU1p7XWo7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRl7 cUxFIxBydgBEfno+ Z0VmWngVVEEuIUIu QkpJFGtXZHphaTUa TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMGQE QBcGVTUmBgUIQSw5 KxEqYlABGEJZKEgq NVIqVBcSIlocBwA2 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z5zIq-0008PV-HF Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 16:38:05 -0000 --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--