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; 
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)
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee
 and game theory
Precedence: list


--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+--