From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WdJG6-0007BY-N8 for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 13:00:10 +0000 Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WdJG5-000159-1D for bitcoin-development@lists.sourceforge.net; Thu, 24 Apr 2014 13:00:10 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id s3OD02Am082675; Thu, 24 Apr 2014 14:00:02 +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 s3OCxvDX084697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 24 Apr 2014 13:59:59 +0100 (BST) Date: Thu, 24 Apr 2014 08:59:53 -0400 From: Peter Todd To: Jorge =?iso-8859-1?Q?Tim=F3n?= Message-ID: <20140424125953.GC16884@savin> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZwgA9U+XZDXt4+m+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 57ecd61a-cbb0-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAYUGUUGAgsB AmIbWlBeUF17WWM7 bAxPbAVDY01GQQRq WVdMSlVNFUsrAmNy TlhqOhl6cwNPfzBx YEFjXz5eWxEpIUB8 E1MHRz8GeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA5TVjU7 QR4DBzAmAUwCQW0v PwduN0UdGklZKEgq NVIqVBcSIlocBwA8 V0hLDGdWLlwMDzYr AARATCYA X-Authentic-SMTP: 61633532353630.1023: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: -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: 1WdJG5-000159-1D Cc: Bitcoin Development Subject: Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory 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: Thu, 24 Apr 2014 13:00:10 -0000 --ZwgA9U+XZDXt4+m+ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 24, 2014 at 12:48:54PM +0200, Jorge Tim=F3n wrote: > Here is a solution to the problem of having 0 confirmation > transactions FWIW I'm running an experiment right now to detect how easy it is to doublespend 0-conf transactions I need to collect more data, but initial results indicate that transaction propagation is sufficiently unreliable that double-spending frequently works without miners using replace-by-fee even when both transactions pay high fees, there is a 60 second delay between first and second, and there's only about four replace-by-fee nodes on the network. With replace-by-fee scorched-earth the success rate of such double-spends would be significantly reduced as the attacker would need to get lucky with bad propagation not just once, but twice in a row. > that relies on game > theory and most miners implementing replace-by-fee and child-pays-for-par= ent. >=20 > This has been proposed before > http://sourceforge.net/p/bitcoin/mailman/message/30876033/ > I'm just going to describe the general idea in more detail. Just to be clear, while that post is mine, original credit for the idea actually goes to John Dillon as far as I know; I first heard about it =66rom him in private discussion. > Replace-by-fee and child-pays-for parent cannot be prohibited by a > protocol rule. > I believe all miners will eventually implement these policies because > it is the more rational way for them to prioritize transactions. > Finally I hope they do because it would make 0-confirmation > transactions possible as described in this post. > So I can't find any reasoning against replace-by-fee unless my example > is terribly flawed. > Am I missing something? A few things: 1) Replace-by-fee doesn't protect against sybil attacks; only confirmations are solid evidence that a transaction has actually reached the mining power and your communication channel to that mining power isn't being blocked. Keep in mind that Bitcoin depends on the existence of a jam-free network, and very importantly, lets you detect when that network has failed and you are being jammed. No unconfirmed transaction scheme can solve this problem in a decentralized network. 2) Replace-by-fee scorched earth does require you to keep private keys online to sign the replacements. Not a big deal, but it's yet another reason why you wouldn't want to use it for high-value stuff. 3) It doesn't directly solve finney attacks(1) where the miner mines the transaction in private. However finney attacks are only relevant if there is high centralization of hashing power, and all other proposed mechanisms, e.g. coinbase reallocation, themselves do a lot of harm to decentralization. (just look at how coinbase reallocation lets large pools bully smaller miners out of business by blacklisting their blocks) One interesting thing with regard to finney attacks and replace-by-fee though is that enforcing hasher visibility of the blocks they are mining - what getblocktemplate was meant to do voluntarily - lets any hasher detect a finney attack double-spend and broadcast it. They have a weak incentive to do so - the scorched earth reply is a high-fee transaction of course and pre-broadcasting transactions makes blocks propagate faster - at which point you're back to a public double-spend. Enforcing visibility of block contents to hashers is definitely a good thing for decentralization. 1) https://bitcointalk.org/index.php?topic=3D3441.msg48384#msg48384 --=20 'peter'[:-1]@petertodd.org 000000000000000093d8af23978adc9e201a1f2e2dc52844f9013a1da3621572 --ZwgA9U+XZDXt4+m+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTWQrEXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDA3NmRiMGVmZjMxN2IzYzkwYWRmODI5ZjYzNzYxODc1NDU3 MzAzODRhZjNhNTlmYjgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuUNwf/WCiJW88po7G4baYAffvsEMwJ oSoj45psfr7m5QoWN8/Px3FHugQ6ch/ce8yjai1wmAB3BH3xKY8gPU2buul2rfXH G/MS3bKLXgQCZEgAmgf64cokg/ICIBL6gzmISgv+ezjZC8A4OJaK0Ngr5xBFwXUz OZlkMzR2GncLJeyT+mxoLwP1ummF+iJCy1X+f5ycb5tVq1Dt53MJcHN9FroTDhYz l7SagPTCJH7XjcZ9YNMauzl7AMeLOmK2QrXZX79I+xBhZ0MpbzZ7IgJZSxg3QmoL B+G+3rbAoCo6gPP+xqXCHmxQKO0//V/X8maNnQUu2zUNBnprTQvZknIAoSok6w== =Gmqj -----END PGP SIGNATURE----- --ZwgA9U+XZDXt4+m+--