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
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
|
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 <john.dillon892@googlemail.com>) id 1USi0J-0006kl-4Z
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Apr 2013 06:07:31 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of googlemail.com
designates 74.125.83.44 as permitted sender)
client-ip=74.125.83.44;
envelope-from=john.dillon892@googlemail.com;
helo=mail-ee0-f44.google.com;
Received: from mail-ee0-f44.google.com ([74.125.83.44])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1USi0H-0005KU-PT
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Apr 2013 06:07:31 +0000
Received: by mail-ee0-f44.google.com with SMTP id c41so1108166eek.3
for <bitcoin-development@lists.sourceforge.net>;
Wed, 17 Apr 2013 23:07:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.15.98.141 with SMTP id bj13mr26451575eeb.29.1366265243421;
Wed, 17 Apr 2013 23:07:23 -0700 (PDT)
Received: by 10.223.197.7 with HTTP; Wed, 17 Apr 2013 23:07:23 -0700 (PDT)
In-Reply-To: <CANEZrP0z6W0ZDsytQ7Rcqb5L6rswn1wv8cbR7c383Dmpzu+gyg@mail.gmail.com>
References: <CANEZrP1yKeQMayFHsEUWtA3=q+v5rPAutjzEFVVHopPGNZ4jGQ@mail.gmail.com>
<453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com>
<CANEZrP0z6W0ZDsytQ7Rcqb5L6rswn1wv8cbR7c383Dmpzu+gyg@mail.gmail.com>
Date: Thu, 18 Apr 2013 06:07:23 +0000
Message-ID: <CAPaL=UVJd3mdd0bs6Oo9vFHnv_6RbFowjmp0tD-ZbOzZxJEJ3g@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Mike Hearn <mike@plan99.net>, bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.4 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(john.dillon892[at]googlemail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (john.dillon892[at]googlemail.com)
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1USi0H-0005KU-PT
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 06:07:31 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Apr 17, 2013 at 9:48 AM, Mike Hearn <mike@plan99.net> wrote:
> So it'd be nice if this ended up not being necessary. Experience indicate=
s that rational miners typically don't pursue a short-termist profit-at-any=
-cost agenda - free transactions have always been included in blocks, miner=
s include transactions even though you could avoid a lot of complexity by j=
ust not including any at all, etc. Some miners like BTC Guild have actually=
sacrificed significant amounts of money for the good of the system. You ca=
n see this in terms of rational self interest - miners earn Bitcoins thus i=
t's in their interest for Bitcoins to be as useful as possible, as that is =
what gives them value. Or you can see it in terms of ideologically-driven a=
ltruism. Or both.
Please don't say Gavin agrees with you. This reminds me of discussing
security in the early days of the internet when the general assumption
that everyone played nice was still correct.
We're seeing huge, expensive, DoS attacks against mining pools,
exchanges, information sites, stores etc. Bitcoin has enemies. Peter
Todd is 100% correct, tx replacement is another form of zero
confirmation transaction and all that has to happen is some subset of
mining power start doing replace by tx fee for it to have no security
while with your proposed implementation opening up a DoS attack
vector.
You also see the DoS attack vector as unimportant and suggest to
handle it as a prioritization problem. "real world experience
indicates that people don't pointlessly mount attacks over and over
again if there's nothing to be gained by doing so." <- of course there
is something to be gained, shutting down a service dependent on tx
replacement, as seen by all the DoS attacks we are seeing. If I were
deciding if my service should use tx replacement and I understood that
it could be trivially shut down, I sure wouldn't be happy I could
"just warn users not to take advantage of the feature whilst the flood
is in progress"
Gavin do you actually agree with Mike on this stuff like he implies?
Because if you do, I think people should know. Myself I wouldn't want
to be contributing to your salary as a foundation member if you don't
take Bitcoin security seriously.
The rapidly-adjusted payments stuff on the Contracts page of the wiki
is broken in multiple ways:
1. (known) Requires DoS vulnerable infrastructure.
2. (known) TX mutability
3. (unknown?) Just doesn't work. Step 5 is to check that T2 is signed
correctly by the access point, and if so, sign T1 and T2. But the
signature of T2 includes the txid of T1 and that isn't known until T1
is fully signed.
That #3 has not been noticed before shows that for all this hot air
no-one has ever bothered making an implementation of the idea. So
Mike, why are you happy to make testnet vulnerable to an unusually
easy DoS attack for an idea you haven't even tried on your own private
testnet with replacement enabled?
Anyway, with Peter Todd's much saner tx-replacement-by-fee the
following can be done:
1. Create a new public key PK1
2. Request a public key PK2 from the access point.
2. Create TX1 with two inputs and two outputs. Both parties sign it
and broadcast it.
access point input -> 2 PK1 PK2 checkmultisig, value =3D input #1 - fee
you input -> 2 PK1 PK2 checkmultisig, value =3D=3D input #2 - fee
3. Create TX2.
TX1 #1 -> pay to access point PK2
TX1 #2 -> pay to yourself PK1 (change)
Set TX2 nLockTime to some time in the future.
4. Set the initial value's of TX2 out #1 and out #2 to the value the
access point and you committed in TX1. Both parties sign with
SIGHASH_SINGLE. (which means both parties are signing for both inputs)
5. Update TX2 as required and sign both inputs. The access point
doesn't need to sign TX2 or give the updated copy of TX2 to the other
party. The TX is not broadcast when updated (like the earlier contract
proposal) although doing so harms no-one.
When the session ends with both parties online, do the following:
1. You sign a version of TX2 with the final output values and nLockTime=3D0
2. If the final output values are acceptable to the access point, they
sign the other half of the 2-of-2 inputs and broadcast. (with whatever
fees required)
If the buyer quits the session abruptly:
1. Access point signs the last (most funds) version of TX2 given to
them, waits until the nLockTime expires, and broadcasts. This also
gets their TX1 input back.
If the access point quits abruptly they can do the above when they go
back online. The buyer has the first, signed, version of TX2 and at
worst can broadcast it eventually to get their deposit back.
Attacks:
After TX1 is signed and broadcast both parties are in on the contract
together, so the funds can't move without the consent of the other.
Both parties can block the movement of the other's deposit, but they
lose their deposit too. With tx mutability there is a small window of
time for a technical mistake, but that should be very, very rare.
You can broadcast an earlier version of the transaction where you pay
less than you were supposed too. However if you do this, the access
point can broadcast a new version of the transaction, splicing
together your signature on the correct output value, with your
signature on an earlier version of the access point's output, thus
paying miners a higher fee than the transaction you broadcast.
Rational miners will chose the latter version rather than your one.
This bidding process can continue until you are out the full amount
you were supposed to pay, with the whole payment going to fees, so why
bother? With nLockTime you don't have a better chance of mining the
transaction than any other miner.
I apologize if the above has already been discussed. I only looked at
the wiki and source code and don't waste too much time reading the
endless bitcointalk forums. The wiki should be updated with these
ideas as they are developed by people and vetted.
Strict replacement by fee should be written so it can be tested
properly and people in the Bitcoin ecosystem use proper security
practices with regard to unconfirmed transactions. I'm willing to
pledge $500USD to anyone who implements it. That is write the core
functionality that does replacement by fee, and a simple 'undo' RPC
command. I would do it myself but my programming is rusty.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJRb4vZAAoJEEWCsU4mNhiPRNoH/jGcGw2NBUcIh0/HT70nnwU+
deaXcdYp9RhDlSf0VGvPwwEAnjWBFc+pYVC+vtL4XEvWR+5PC7FcOrRrv/+sTDPs
YwPkCIwvXJizFe5pAhXOde4EdibXU0WXTLonMNUeZkwhxUfrczURm2tgmJlNE7nA
3PBun4c4r7EcdRHuh9SiK0C4RgB5w63t/qyFVUfqwhyKYiS55K/2t2mVLLxcPWkY
8nxlYlese5eZZJBTfiePtPOqTd43DHOkN+4Iu5XXQIH7v2QHf50DMqgI3iVLVe08
c2i9GutwX+2MevSMe/S57952BCjBq4zF0nBpaAfIFCVHDDZ6bDbgA7fUjDtLVds=3D
=3D1Tc0
-----END PGP SIGNATURE-----
|
