1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
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+--
|
