Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5xlu-0000dn-Ob for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 14:59:58 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.102 as permitted sender) client-ip=62.13.148.102; envelope-from=pete@petertodd.org; helo=outmail148102.authsmtp.net; Received: from outmail148102.authsmtp.net ([62.13.148.102]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Z5xlt-00068a-HZ for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 14:59:58 +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 t5JExlXA026651; Fri, 19 Jun 2015 15:59:47 +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 t5JExfKx045989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 19 Jun 2015 15:59:43 +0100 (BST) Date: Fri, 19 Jun 2015 10:59:41 -0400 From: Peter Todd To: Adrian Macneil Message-ID: <20150619145940.GB5695@savin.petertodd.org> References: <20150619103959.GA32315@savin.petertodd.org> <20150619135245.GB28875@savin.petertodd.org> <20150619140815.GA32470@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v9Ux+11Zm5mwPlX6" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: d203f996-1693-11e5-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwsUEkAaAgsB AmMbWlFeVVR7XWc7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRl7 c1ZIKVFycwBPcHc+ ZENhXHAVCEZ6dhB0 S0hJFGsPZnphaTUa 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: 1Z5xlt-00068a-HZ 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:59:58 -0000 --v9Ux+11Zm5mwPlX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 19, 2015 at 07:30:17AM -0700, Adrian Macneil wrote: > > In that case would you enter into such contracts? > > >=20 > We take it as it comes. >=20 > 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. --=20 'peter'[:-1]@petertodd.org 00000000000000000fe727215265d9ddacb2930ad2d45920b71920b7aed687f1 --v9Ux+11Zm5mwPlX6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVhC5ZXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwMzkzMjQ1ODA1NWM2OGQ0ZWUyYjZkNjg0NDFjNDc2NGVm YmRmNmIwYjE2ODM3MTcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftGsAgAp74fT075d9olKniHz119eDt7 MDlZXKbGyccuApnSktMrSY1QLZ7/R1CWbcC+TK9m+sVzWDH2YBiVWFRLrXZvI8Iq 4s2zFdZs3E2y4OxOdtM6f8vIvz1FrG9TgqCSYt/vsTfTDjo15qu5I0ZV4joo5XSy dedHTHFms8q/ZVma3Y2Y4qfjuqGMWlrfYxbwmApmrQy3/3mVxxVgARw/htzOMLX1 SFekQowqpVZQ1NZmNvBcd/afXo98Ssq3bx6a8wjONMzNYRdAgCpTkqkfplQiBAM6 TWBT116V2zej6rQdcEIe4GI5CErVNlrFQ+2h4ig5rMsHnRZ0D5VxONoZirW0CA== =xv2T -----END PGP SIGNATURE----- --v9Ux+11Zm5mwPlX6--