From mboxrd@z Thu Jan 1 00:00:00 1970 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 1Z5wy9-00068N-88 for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 14:08:33 +0000 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; Received: from outmail149075.authsmtp.net ([62.13.149.75]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Z5wy8-0003uD-12 for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 14:08:33 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5JE8M6j050294; Fri, 19 Jun 2015 15:08:22 +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 t5JE8FOg044884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 19 Jun 2015 15:08:18 +0100 (BST) Date: Fri, 19 Jun 2015 10:08:15 -0400 From: Peter Todd To: Adrian Macneil Message-ID: <20150619140815.GA32470@savin.petertodd.org> References: <20150619103959.GA32315@savin.petertodd.org> <20150619135245.GB28875@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: a2bfd31e-168c-11e5-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwsUEkAaAgsB AmMbWlFeUFV7WGs7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRl7 cxZoLU5ycwFOcHo+ ZENgXnAVDUYoIxJ+ QxtJFGsONnphaTUa 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 X-Headers-End: 1Z5wy8-0003uD-12 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 14:08:33 -0000 --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--