From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WekGc-0006xe-6x for bitcoin-development@lists.sourceforge.net; Mon, 28 Apr 2014 12:02:38 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.161 as permitted sender) client-ip=62.13.148.161; envelope-from=pete@petertodd.org; helo=outmail148161.authsmtp.com; Received: from outmail148161.authsmtp.com ([62.13.148.161]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WekGZ-0007Fo-Ri for bitcoin-development@lists.sourceforge.net; Mon, 28 Apr 2014 12:02:38 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s3SC2TXp037148 for ; Mon, 28 Apr 2014 13:02:29 +0100 (BST) Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s3SC2Ox3070083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 28 Apr 2014 13:02:26 +0100 (BST) Date: Mon, 28 Apr 2014 08:02:09 -0400 From: Peter Todd To: bitcoin-development@lists.sourceforge.net Message-ID: <20140428120209.GJ20078@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zOcTNEe3AzgCmdo9" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: f790a756-cecc-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXQ11 IQgLXVBSFQF4AB8L BhwUUB48cANYeX5u ZEFqQHFbVVt/fUFi QwAXFg51Zxgoa2AY UEBQdE1ccQJMMElC Y1AuU3YLfDZSNSl9 RlY+ZHVgYTtWbXwN GFxcdVtLGhsHRSgG SggGFD4iWEcUAis+ IlQ9IVkGF0YcPgA/ OEE9WRoHMgMSDRBC V0pNAStVYkEIVjFu AwRAGFYXCjBbXU9N X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -0.4 (/) 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 1.1 TRACKER_ID BODY: Incorporates a tracking ID number X-Headers-End: 1WekGZ-0007Fo-Ri Subject: [Bitcoin-development] Replace-by-fee scorched-earth without child-pays-for-parent 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: Mon, 28 Apr 2014 12:02:38 -0000 --zOcTNEe3AzgCmdo9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Someone who wanted to remain anonymous sent me in this idea, which I'll admit I'm kicking myself for not having thought of earlier. They sent me this hash so they can claim credit for it later should they choose to reveal their identity: bb0de552f81fa356b99fbeef65fa532bb58111184efee2cbe92f66509af8d151 When Alice wants to pay Bob x bitcoins, rather than creating a single transaction, tx1, that does that, she creates a pair of transactions, with the second, tx2, spending the same inputs and an input provided by Bob, but paying x*k bitcoins to fees. Should Bob detect a double-spend he simply signs the extra input, making it clear that he intended for the countermeasure to be deployed, and broadcasts tx2. This mechanism has two advantages: 1) child-pays-for-parent isn't required at avoiding changes to the relaying code and letting the counter-transaction propagate quickly. 2) k can be adjusted such that Alice is guaranteed to be worse off for attempting a double-spend even taking into account the probability of getting away with it. For instance, right now if just, say, Eligius adopted replace-by-fee a k value of 20 would still make double-spends unprofitable. However it does require payment protocol support. This lead me to realize that if Alice signs all her inputs with the ANYONECANPAY sighash bit set Bob can get the same effect by adding his own inputs to bump the effective fee. While of course the funds to do so come out of his own pocket, they are balanced out by the payment to him, with the net effect being the same as the child-pays-for-parent version. Additionally in the common case of "Bob would like Alice's transaction to go through sooner" this also gives Bob the flexibility to add small sized inputs at will to bump fees. (or for that matter Alice, giving a small privacy boost) Using ANYONECANPAY does have one disadvantage in that transactions using it are always malleable. However an "attacker" doing so is forced to spend funds to do that. Secondly after the recent malleability attacks wallet handling of malleability-related problems has greatly improved. Finally it's worth noting how the k-overpaying version of scorched-earth gives Finney attacking(1) miners - such as BitUndo - incentives to defect knowing that they can earn significantly more fees by publishing their supposedly secret transactions to the p2p network. Equally even in the ANYONECANPAY version merchants may decide that discouraging fraud is worth an overpayment. 1) https://bitcointalk.org/index.php?topic=3D3441.msg48384#msg48384 --=20 'peter'[:-1]@petertodd.org 0000000000000000603b189f99cf2a95ce01835596b5d5fbd8c5725c11f504ee --zOcTNEe3AzgCmdo9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTXkM8XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDA0YzI4NTFiNmEwYTYzNTY1ZTRlYzQzYTU2YTk5ZjRlMTky MTk1YjI0YzM2NGJhZWYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsseAgAgBpsLaY9SMq3y9HAQE5Dqq1w sYZi2QvOQjYgubO6zdWHbCumBRQ4HIjwYgBOj0boMgPj8VJD1JuXKiRzDz4O76KJ dm493++liYBgDmjRxz+EGvW2XKaUl8YlgXvVcD8TVGaNYKt0Ox9D37D7q/00RIGd blwzCAf80Qt1FLx/iDs6fDoJ4UzmCksRzl/V5j47yrYm3Bcz26dEf23fDNFzGbz1 WgIOS28Nrg5gz6oZsczWRneGEOYXQp9KGOscoE2bB/OKRXkf5HMN7EpyvRJwmQNG FPygtwDOFn3N0S6dmrioEwOeHnPjOhOk/M7FC4rXGTid+LRWLbGd5BEVXdHV7g== =ClXw -----END PGP SIGNATURE----- --zOcTNEe3AzgCmdo9--