diff options
| author | Peter Todd <pete@petertodd.org> | 2014-04-24 08:59:53 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-04-24 13:00:10 +0000 |
| commit | 70a04dfee1c5e7f38da8ff97c66fc7940d41a8d9 (patch) | |
| tree | 53baa3c480ba9bfd77ec41ac32c71d609e769c6d /fa/13551d3baf3ce818a8b711c4b37befedbab22e | |
| parent | e9795085cbc0a161c2c08177dc9ed876ca65079e (diff) | |
| download | pi-bitcoindev-70a04dfee1c5e7f38da8ff97c66fc7940d41a8d9.tar.gz pi-bitcoindev-70a04dfee1c5e7f38da8ff97c66fc7940d41a8d9.zip | |
Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory
Diffstat (limited to 'fa/13551d3baf3ce818a8b711c4b37befedbab22e')
| -rw-r--r-- | fa/13551d3baf3ce818a8b711c4b37befedbab22e | 173 |
1 files changed, 173 insertions, 0 deletions
diff --git a/fa/13551d3baf3ce818a8b711c4b37befedbab22e b/fa/13551d3baf3ce818a8b711c4b37befedbab22e new file mode 100644 index 000000000..3f4de80d1 --- /dev/null +++ b/fa/13551d3baf3ce818a8b711c4b37befedbab22e @@ -0,0 +1,173 @@ +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 <pete@petertodd.org>) 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 <pete@petertodd.org> +To: Jorge =?iso-8859-1?Q?Tim=F3n?= <jtimon@monetize.io> +Message-ID: <20140424125953.GC16884@savin> +References: <CAC1+kJM3pSq8YfwbX167rQ0=0Y_hozRQ3pggDN524=LUfOdTqg@mail.gmail.com> +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: <CAC1+kJM3pSq8YfwbX167rQ0=0Y_hozRQ3pggDN524=LUfOdTqg@mail.gmail.com> +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 <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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+-- + + |