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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YkWUa-0005RE-B1 for bitcoin-development@lists.sourceforge.net; Tue, 21 Apr 2015 11:37:28 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.95 as permitted sender) client-ip=62.13.149.95; envelope-from=pete@petertodd.org; helo=outmail149095.authsmtp.com; Received: from outmail149095.authsmtp.com ([62.13.149.95]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YkWUY-0007yI-AG for bitcoin-development@lists.sourceforge.net; Tue, 21 Apr 2015 11:37:28 +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 t3LBbJvJ074491; Tue, 21 Apr 2015 12:37:19 +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 t3LBbFCX046099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Apr 2015 12:37:18 +0100 (BST) Date: Tue, 21 Apr 2015 07:37:14 -0400 From: Peter Todd To: Adrian Macneil Message-ID: <20150421113714.GA3455@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: c4521b85-e81a-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAMUGUUGAgsB AmMbWlZeU1p7WGs7 bA9PbARUfEhLXhtr VklWR1pVCwQmRR99 dExoIXFycwNGcXc+ ZENnXXIVD0B/d0cv SktJQGUHNHphaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMjkh TRQPVS43EEsJRiM8 ZxUgJhYGEV4VO04/ eVEwEVwVPnc8 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: 1YkWUY-0007yI-AG Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Double spending and 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: Tue, 21 Apr 2015 11:37:28 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 08, 2015 at 11:28:08PM -0700, Adrian Macneil wrote: > Fwiw, Coinbase relies on the current first-seen mempool behaviour. Wide a= doption of RBF (without a suitable replacement available) would make it ext= remely difficult to pitch bitcoin as a viable alternative to credit cards p= ayments to large merchants. Some questions: 1) Are you contractually obliged to accept zeroconf transactions with existing customers? I keep hearing rumors of this, but would like some confirmation. In particular, it would be good to know if you have the option of turning zeroconf off at all, contractually speaking. 2) What are your double-spend losses to date? 3) Are you actively marketing zeroconf guarantees to new customers? You're API is a bit unclear as to what exactly those guarantees are; looks like they only apply if a merchant has "convert to fiat" turned on. 4) What are your short, medium, and long term plans to move away from dependency on "first-seen" mempool policy? e.g. hub-and-spoke payment channels, Lightning network, off-chain, etc. 5) What is your plan for new Bitcoin Core releases that break zeroconf via changed tx acceptance rules? Basically every release we've ever made has added a zeroconf exploit due to different tx acceptance rules. (e.g. my 95% success rate last summer) 6) What are your plans for Bitcoin Core releases that fundementally break zeroconf? For instance changes like limiting the mempool size create zeroconf vulnerabilities that can't be avoided in many situations. Yet they may also be unavoidably needed for, for instance, DoS protection. Will you oppose these improvements? 7) If a mining pool adopts adopted policy that broke zeroconf, e.g. replace-by-fee, would you take any action? 8) Would you take legal action against a mining pool for adopting replace-by-fee publicly? 9) Would you take action against a mining pool who is mining double-spends without explanation? e.g. one that claims not to be running non-Bitcoin Core policy, but keeps on mining double-spends. --=20 'peter'[:-1]@petertodd.org 0000000000000000089abd68efc18c03d2a294295f3706a13966613a3ff3b390 --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVNjZlXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwM2EwNjM1MzE5OGViYTYyMzc2NmE3MTE2NmRlOWQ2MjE2 ZTFlYjRiYWQ4ZDYyZmMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftypwf/bMkA7nzKa/telOR4yjgK0/nJ I/9i1lpTyRmylLXP2jsPdk54qZ0RHFO9NnMiCz42Cbp7APuubuBhxSLknQsPgYtK YL2bgJJFNBDCV0dXha6anmhfyVZh3OYbZ8pylBJthKRfS2oYom4gCyroPppAlh7/ gVZkKwxOb4SBLPw6NlO5q52UmMvJSzXmN4J4uSOsM/CdRGt3EzkWpMJVW7LiaJ3R MHA8NJQCnOOlYkEGZAALgJYnYbB//2NfUthv21p68cnOLA84RObci/pg0WNJxgm6 z2EdivpzPVyDHjo/cgiptpcQK9zsM04H27i85qjGDli2jBDJKvwpL8I0nX0QEw== =lNZQ -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV--