From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UemGg-0000IP-P7 for bitcoin-development@lists.sourceforge.net; Tue, 21 May 2013 13:06:18 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.96 as permitted sender) client-ip=62.13.148.96; envelope-from=pete@petertodd.org; helo=outmail148096.authsmtp.net; Received: from outmail148096.authsmtp.net ([62.13.148.96]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UemGe-0004Mz-Tj for bitcoin-development@lists.sourceforge.net; Tue, 21 May 2013 13:06:18 +0000 Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt9.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r4LD67eN006867; Tue, 21 May 2013 14:06:07 +0100 (BST) Received: from tilt (dhcp184-48-74-214.hil-sckmthx.sjc.wayport.net [184.48.74.214]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r4LD5x1P026666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 May 2013 14:06:03 +0100 (BST) Date: Tue, 21 May 2013 06:05:57 -0700 From: Peter Todd To: Gregory Maxwell Message-ID: <20130521130534.GA27580@tilt> References: <519AC3A8.1020306@quinnharris.me> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 317eaac6-c217-11e2-b10b-0025903375e2 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAMUFVQNAgsB AmUbWlBeUFt7WWc7 agJVcwFVfE1KQQdr VFdMSlVNFUsqBWB1 A1YfMhlwcQNAfjBx YUFrXD5YXUMvJBcu RFMHF2wBeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4nGSM2 Qx1KJi0iG0FNYSIv LhInIVcAHUEXWgAA X-Authentic-SMTP: 61633532353630.1019:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 184.48.74.214/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: 1UemGe-0004Mz-Tj Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Double Spend Notification 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 May 2013 13:06:19 -0000 --LyciRD1jyfeSSjG0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 20, 2013 at 08:54:25PM -0700, Gregory Maxwell wrote: > One point that was only recently exposed to me is that replacement > combined with child-pays-for-parent creates a new kind of double spend > _defense_: If someone double spends a payment to an online key of > yours, you can instantly produce a child transaction that pays 100% of > the double spend to fees... so a double spender can hurt you but not > profit from it. (and if your side of the transaction is > potentially/partially reversible he will lose)... You can do better than that actually: you can arrange the transaction such that the double-spender is hurt by asking them to pay an excess on top of the initial payment, and having that excess get returned to them in a subsequent transaction. Of course, that's trusting the merchant, but you're trusting the merchant to ship to a product anyway so... A really interesting example for this though would be applications where you are making a deposit. You credit the customer account immediately with half of the deposit amount, allowing them to immediately spend that portion for something transferable. (perhaps an alt-coin) If the customer tries to double-spend you burn half to fees, still leaving the other half to pay for what they did spend. If they don't double-spend, the rest of the balance becomes available after n confirmations. A BTC->alt-coin exchange could use this mechanism for instance, although it only works with widespread replace-by-fee adoption; blockchain.info's shared-send service is another application, as is SatoshiDice. (the failed bet tx can be the refund) What's nice here is even if the customer tries to pay a miner to do the dirty work, a short-term rational miner still has an incentive to screw over the customer by accepting the merchant's double-spend. Now the customer can promise the miner future business, but they've shown themselves to be dishonest... how much honor is there among thieves? --=20 'peter'[:-1]@petertodd.org 00000000000000f31f5cd20f915e3edb8e3fceea49580235b984fea63f1f882c --LyciRD1jyfeSSjG0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRm3EyAAoJEH+rEUJn5PoE0lMIAIFuhpTM+ZELXNYLay9461Kr 42vN7QiSz6qgQODac9XYxUAqTFd6UHmpe2BnpdjpsVdmK3daq0XShPxOL0XuZjL5 7/7gIZoty/f3wVVHjGqE4OVpTxIU1ZcmrNkY87bjKx7kffNTNoKyYQXicWIfJgJl STN15Y615T46llwQS85TpZ7cKwOi55BJehL7QHDQc0e1hS95Yu504s3rQEnZJlnE 62xZpwlkwHjmG4YV3ZCLoFvqR6LbBNPURkJPBGi2X/pxhbn0jqsv/dlYS8G25UWG ZY+WL73VyDgjlKdLph6fsSoGYnNfCB5C1y1a7GQxuciu6TcNzdLQjHQRF2ESjAU= =fkoJ -----END PGP SIGNATURE----- --LyciRD1jyfeSSjG0--