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
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1USllN-000371-PW
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Apr 2013 10:08:21 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.154 as permitted sender)
client-ip=62.13.148.154; envelope-from=pete@petertodd.org;
helo=outmail148154.authsmtp.co.uk;
Received: from outmail148154.authsmtp.co.uk ([62.13.148.154])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1USllM-0003bC-3i for bitcoin-development@lists.sourceforge.net;
Thu, 18 Apr 2013 10:08:21 +0000
Received: from mail-c226.authsmtp.com (mail-c226.authsmtp.com [62.13.128.226])
by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r3IA8DoN020363; Thu, 18 Apr 2013 11:08:13 +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 r3IA86Dk081280
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 18 Apr 2013 11:08:09 +0100 (BST)
Date: Thu, 18 Apr 2013 06:08:06 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20130418100806.GA13908@savin>
References: <CANEZrP1yKeQMayFHsEUWtA3=q+v5rPAutjzEFVVHopPGNZ4jGQ@mail.gmail.com>
<453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com>
<CANEZrP0z6W0ZDsytQ7Rcqb5L6rswn1wv8cbR7c383Dmpzu+gyg@mail.gmail.com>
<CAPaL=UVJd3mdd0bs6Oo9vFHnv_6RbFowjmp0tD-ZbOzZxJEJ3g@mail.gmail.com>
<CANEZrP3ocAJNoQ3xJqRTL8Gz3_T8xsCPPAvSfEOYpPo76wgbig@mail.gmail.com>
<20130418090444.GA30995@savin>
<CANEZrP0AYaWnVhrAbMXP0BGhb=CZMg_-PYVzwKbcCoRKC9V2rw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY"
Content-Disposition: inline
In-Reply-To: <CANEZrP0AYaWnVhrAbMXP0BGhb=CZMg_-PYVzwKbcCoRKC9V2rw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: df7ce56e-a80f-11e2-98a9-0025907ec6c5
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwoUGUUGAgsB AmUbWlVeUFV7WGM7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqAmVw DhhqCRl6dgdOeDBy YEZmXj4PCkMpIEN7
F1MFHW1QeGZhPWIC WUgJfh5UcAFPdx9C PwN5B3ZDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4iGCI9 DzwFJn0hGldNWzV7
NRE+LlcXEUMcNFla
X-Authentic-SMTP: 61633532353630.1020: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: 1USllM-0003bC-3i
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
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, 18 Apr 2013 10:08:21 -0000
--OXfL5xGRrasGEqWY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Apr 18, 2013 at 11:28:48AM +0200, Mike Hearn wrote:
> Let's include bandwidth. Say the contract (multi-sig input + the outputs)
> is about 700 bytes. 43,200 transactions is then about 29 megabytes of dat=
a.
> On a fairly normal 10mbit connection that would take about 23 seconds to
> transfer. Of course the real number is a bit higher because of latency
> introduced by the inv/tx round-tripping. So the time window of the attack
> is dominated by bandwidth but it's still quite small compared to the block
> solving window.
Mike, for the love of god, it's not acceptable to require Bitcoin
validating and mining nodes to buy unlimited bandwidth. The attacker
just has to spend more outgoing bandwidth than some fraction of the
network hashing power has incoming bandwidth (individually speaking) for
convergence to fail.
But anyway, as I said in my follow up email, with correct prioritization
it's probably a tractable problem.
> It's *easily* DoSable, not trivially.
> >
>=20
> What I meant is - find some open DNS resolvers, start firing packets at
> testnet nodes, done. You don't have to do protocol level attacks to just
> render nodes useless.
Testnet has 40 nodes online right now that can be seen by my seeder. To
shut down all those nodes with a standard DoS attack would take at least
40 times more bandwidth than required by a tx-replacement DoS attack.
> Having a single multi-sig input means you can't do that because both
> parties co-operate to update the single input, but schemes that use
> multiple inputs do seem posible.
You can always add dummy inputs.
> > How exactly do you envision replacement working with non-final =3D=3D
> > non-standard anyway?
> >
>=20
> As I said at the bottom of my second mail, it means making non-final
> transactions relayable again, but only to nodes that advertise a high
> enough version number. Those nodes are expected to do something intellige=
nt
> with them, like just not put them in the wallet (unless the user has opted
> in and ticked the "i know what i'm doing" box, perhaps).
Well, all that making them relayable enables is letting all parties to a
transaction be offline when the nLockTime expires, so I'm not really
sure it's worth doing, at least immediately. Weakening the non-final =3D=3D
non-standard test to give a window of, say, 3 blocks, would be fine I
think.
> Well, it depends on your use case - you need to cast the (fixed) algorithm
> into a network protocol, manage the interactions between the parties,
> monitor the network for malicious broadcasts so you can replace them, fix
> the code so the wallets don't accept non-final transactions except when
> taking part in your contract, etc. If you do it all with Bitcoin-Qt it's
> easier but then your app can't easily run in places that can't afford a f=
ew
> hundred megs of ram (like wifi hotspots). The devil is in the details.
The whole point of tx-replacement by fee is that the algorithm doesn't
need to be fixed. It makes it very clear that unconfirmed transactions
aren't trustworthy, and levels the playing field between you and people
posessing lots of hashing power. Nodes can independently choose their
replacement policy and the system still works. It also makes adjusting
fees after the fact easy, again, functionality that we really need right
now.
John's adjusting micropayments proposal would work best in conjuction
with some reputation stuff, like buying a fidelity bond promising you
will play nice with tx replacement. Implementing such bonds is a bit
subtle, because random chance can cause an earlier tx to be mined rather
than a latter, but you can, for instance, rebut accusations of fraud in
that case by simply creating an additional tx that pays the full amount
if a partial tx accidentally gets mined. Come to think of it, such a
system could be useful for inter-bank settlement, providing a security
guarantee somewhere between a standard transaction and a fully off-chain
transaction, at the cost of a single transaction fee.
More importantly, it's not subject to sudden "oh shit, slush's pool got
hacked and is doing double spends!" disasters. People should not be
trusting multiple mining pools run by individuals as hobbies on insecure
VPS services with the security of their payments, and zero-conf
transactions do exactly that. Not to mention the ~25% of hashing power
controlled by parties of unknown origin.
--=20
'peter'[:-1]@petertodd.org
--OXfL5xGRrasGEqWY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJRb8YFAAoJEH+rEUJn5PoEVXIH/1LeeTaDaiF//lduQchcsoul
H32CZkQ7eHzeHOrOhuhJXM2x6K3rOvtsK8To4Q157d93qskXAqmNeOI5ZwGHSNi4
loRePp7+teny6y2lo0YwlPQEj7GEbGyKVqrziokkeuTeOnJU/X6VnD1/HH0sXSA6
qihlHdbPvbPxLEMm+Nyo3tWyi8MBvz2v2fo1At3ZtT9UfuGQokYipnKhvxSQD0vF
UgWcGNLkLBjRdwWOmk5vP167FwpOTI3OydhxdnS083fesFiPxSTSgy4aet1Aw/MX
uqAooTQPmznM7uS0zlbRZ9PZocAapgfpx9Qsl7Vb8nLFk2taPhpAVDZnkIIIry0=
=rz4o
-----END PGP SIGNATURE-----
--OXfL5xGRrasGEqWY--
|
