summaryrefslogtreecommitdiff
path: root/82/b9fdbb2524e904580e211546d5a8ec09d0ad86
blob: 22d1657135ab02e85b0f2830ab7cc3a25be99ace (plain)
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
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 1YPa55-00061H-Ca
	for bitcoin-development@lists.sourceforge.net;
	Sun, 22 Feb 2015 17:12:35 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.93 as permitted sender)
	client-ip=62.13.148.93; envelope-from=pete@petertodd.org;
	helo=outmail148093.authsmtp.net; 
Received: from outmail148093.authsmtp.net ([62.13.148.93])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1YPa53-0003Br-IK for bitcoin-development@lists.sourceforge.net;
	Sun, 22 Feb 2015 17:12:35 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t1MHCRxZ085558;
	Sun, 22 Feb 2015 17:12:27 GMT
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
	[75.119.251.161]) (authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t1MHCNvi097504
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Sun, 22 Feb 2015 17:12:25 GMT
Date: Sun, 22 Feb 2015 12:12:22 -0500
From: Peter Todd <pete@petertodd.org>
To: Tom Harding <tomh@thinlink.com>
Message-ID: <20150222171222.GA30816@savin.petertodd.org>
References: <20150212064719.GA6563@savin.petertodd.org>
	<54EA0571.4050107@thinlink.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl"
Content-Disposition: inline
In-Reply-To: <54EA0571.4050107@thinlink.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: f9335106-bab5-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdAAUHlAWAgsB AmMbWlNeUV97W2U7 bA9PbARUfEhLXhtr
	VklWR1pVCwQmRR18 fm1gFEByfgJDeHo+ ZERhWngVCk15dkN8
	QkhJRzxUYHphaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
	NQ4vNDcwO3BTJTpY RgYVKF8UXXNDBDMk QxkJEHAlDAgLSih7
	MURgcwZaRFwabi0A 
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/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
	-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YPa53-0003Br-IK
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
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: Sun, 22 Feb 2015 17:12:35 -0000


--BXVAT5kNtrzKuDFl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 22, 2015 at 08:36:01AM -0800, Tom Harding wrote:
> On 2/11/2015 10:47 PM, Peter Todd wrote:
> >My replace-by-fee patch is now available for the v0.10.0rc4 release:
> >
> >     https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4
> >
>=20
> This patch immediately simplifies successful double-spends of
> unconfirmed transactions.  But the idea that it "gives a path to
> making zeroconf transactions economically secure" is quite dubious.
>=20
> * You don't provide sufficient means to detect and relay
> double-spends, which is necessary to trigger a scorched-earth
> reaction.  Not all double-spends will conform to your replacement
> rules.

No, OTOH if they don't then the situation is no difference from what we
have now, and replace-by-fee does no harm. Meanwhile, relaying of bare
double-spend signatures can be implemented in the future, as I suggested
last year for your/Andresen's double-spend relaying patch.

Did you notice the even more obvious way to defeat ANYONECANPAY scorched
earth with that patch?

>   * Maybe XT nodes would help to overcome this.  But meanwhile, in
> the ANYONECANPAY design, Bob's replacement is a triple-spend.  Even
> XT nodes won't relay it.

So? RBF nodes will.

> * It's unclear when, if ever, any senders/receivers will actually
> try to use scorched-earth as a double-spend deterrent.

I suspect many won't, because few people need to rely on unconfirmed
transactions anyway.

> Also, this patch significantly weakens DoS protections:
>=20
> * It removes the early conflict check, making all conflict
> processing more expensive

If you're going to consider replacement, conflict processing will
definitely be more expensive. :)

An actual DoS attacker would do their DoS attack in a way where conflict
processing has nothing to do with it, so this change does no actual
harm.

>   * There is no attempt to protect against the same transaction
> being continually replaced with the fee bumped by a minimal amount.

What exact git commit were you looking at? I did have an early one that
did have a bug along those lines, now fixed.

The current version ensures every replacement pays at least as much
additional fees as would normally cost to broadcast that much data on
the network, and additionally requires the fees/KB to always increase;
under all circumstances it should be no more of a DoS threat than
low-fee transactions are otherwise. I'd like to know if there is a flaw
in that code however!

--=20
'peter'[:-1]@petertodd.org
000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8

--BXVAT5kNtrzKuDFl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJU6g3yXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxN2MyZjM0NmY4MWU5Mzk1NmM1Mzg1MzE2ODJmNWFmM2E5
NWY5Yzk0Y2I3YTg0ZTgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuYGgf/ZlcDZx7LmSQ99Oz+K7EHEKQL
OxLcgvZc+Ondnf0FYgO02oYyQi1XMpoZ6tV1gre12EeDKpafXI5hTpb/78/puZS3
4HabFxMXgz/0PKSj171Ew95EoEpp8jAG/xJwpnL/pdXmbFLrcZ3n+Of6dExn+QLV
DQs5kax5bhFkZ04QKFhYlW229OiKZoprEKTWdjSEPVSutkHChNC2jy2QHOBQoxoW
ANEy4762JRTbUFVw3KXNgIy5aeF7xlL2HHKIwsSrmpZTJSa4zeIt0FTH2ZyUflib
g/+NZ9q1LrH3fQtqAP9c8L7ovrFIK9DrPkVYtThFhnFv7H07wup2dfRrHSMOYg==
=kerc
-----END PGP SIGNATURE-----

--BXVAT5kNtrzKuDFl--