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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1USOzC-00042s-Lv
for bitcoin-development@lists.sourceforge.net;
Wed, 17 Apr 2013 09:49:06 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.43 as permitted sender)
client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f43.google.com;
Received: from mail-oa0-f43.google.com ([209.85.219.43])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1USOzB-0006LY-Jg
for bitcoin-development@lists.sourceforge.net;
Wed, 17 Apr 2013 09:49:06 +0000
Received: by mail-oa0-f43.google.com with SMTP id l10so1396650oag.16
for <bitcoin-development@lists.sourceforge.net>;
Wed, 17 Apr 2013 02:49:00 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.96.105 with SMTP id dr9mr1273453oeb.59.1366192139573;
Wed, 17 Apr 2013 02:48:59 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.167.169 with HTTP; Wed, 17 Apr 2013 02:48:59 -0700 (PDT)
In-Reply-To: <453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com>
References: <CANEZrP1yKeQMayFHsEUWtA3=q+v5rPAutjzEFVVHopPGNZ4jGQ@mail.gmail.com>
<453bfc69-b2ab-4992-9807-55270fbda0db@email.android.com>
Date: Wed, 17 Apr 2013 11:48:59 +0200
X-Google-Sender-Auth: NDfWdiTrWMEWwfznjFarjjeLZeM
Message-ID: <CANEZrP0z6W0ZDsytQ7Rcqb5L6rswn1wv8cbR7c383Dmpzu+gyg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e012280f22ca3f504da8b6588
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1USOzB-0006LY-Jg
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: Wed, 17 Apr 2013 09:49:06 -0000
--089e012280f22ca3f504da8b6588
Content-Type: text/plain; charset=UTF-8
When this system was first being discussed, Gavin was concerned that miner
incentives were to ignore replacements because it meant extra work and the
replacement might have equal or lower fees than before (or indeed, no
fees). He proposed two solutions: one is to progressively raise the fee on
each replacement. The other is to specify lock time in terms of blocks and
then step it backwards once for each replacement, thus ensuring that by
replacing the transaction you get to claim any attached fee earlier.
It should be apparent that both solutions can be implemented by whichever
application is running the contract - the core Bitcoin network and software
is agnostic either way.
Now, Gavin and I disagreed on whether this would actually be necessary. As
I already pointed out, both solutions seriously reduce the utility of HFT
because they limit how often you can update the contract. Instead of an
online game billing you per second, maybe it can only do it per minute or
per 10 minutes with the lock time solution because otherwise you run out of
blocks, and with ever-increasing fees perhaps the contract becomes too
expensive to justify after a while.
So it'd be nice if this ended up not being necessary. Experience indicates
that rational miners typically don't pursue a short-termist
profit-at-any-cost agenda - free transactions have always been included in
blocks, miners include transactions even though you could avoid a lot of
complexity by just 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 can see this in terms of rational self interest - miners
earn Bitcoins thus it'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 altruism. Or both.
If I were to implement an application that used tx replacement, I would
probably start with replacements that don't change the fees and don't count
down the lock time field. We can then observe whether miners bother
changing their software to behave differently, or whether the inherent
utility of the application is enough to convince them to play by the
default rules. Ideally at least one application made possible by this
feature is a "killer app" - something so useful / unique / compelling that
people want to obtain Bitcoin just to use it. If someone can find such an
app, then rational miners should want tx replacement to work as reliably as
possible because it boosts the value of their earnings.
There are some other misc details - reactivation requires that we bump the
protocol version and start relaying non-final transactions to new nodes
again. Those nodes should relay replacements but not let them enter wallets
unless/until the wallet software itself can handle them better, for
instance, by communicating via APIs anticipated confirmation times. This is
something for individual wallet APIs to handle on their own, and just
ignoring non-final transactions is a perfectly workable approach for
Bitcoin-Qt.
--089e012280f22ca3f504da8b6588
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">When this system was first being discussed, Gavin was conc=
erned that miner incentives were to ignore replacements because it meant ex=
tra work and the replacement might have equal or lower fees than before (or=
indeed, no fees). He proposed two solutions: one is to progressively raise=
the fee on each replacement. The other is to specify lock time in terms of=
blocks and then step it backwards once for each replacement, thus ensuring=
that by replacing the transaction you get to claim any attached fee earlie=
r.<div>
<br></div><div style>It should be apparent that both solutions can be imple=
mented by whichever application is running the contract - the core Bitcoin =
network and software is agnostic either way.</div><div style><br></div>
<div style>Now, Gavin and I disagreed on whether this would actually be nec=
essary. As I already pointed out, both solutions seriously reduce the utili=
ty of HFT because they limit how often you can update the contract. Instead=
of an online game billing you per second, maybe it can only do it per minu=
te or per 10 minutes with the lock time solution because otherwise you run =
out of blocks, and with ever-increasing fees perhaps the contract becomes t=
oo expensive to justify after a while.</div>
<div style><br></div><div style>So it'd be nice if this ended up not be=
ing necessary. Experience indicates that rational miners typically don'=
t pursue a short-termist profit-at-any-cost agenda - free transactions have=
always been included in blocks, miners include transactions even though yo=
u could avoid a lot of complexity by just not including any at all, etc. So=
me miners like BTC Guild have actually sacrificed significant amounts of mo=
ney for the good of the system. You can see this in terms of rational self =
interest - miners earn Bitcoins thus it's in their interest for Bitcoin=
s to be as useful as possible, as that is what gives them value. Or you can=
see it in terms of ideologically-driven altruism. Or both.</div>
<div style><br></div><div style>If I were to implement an application that =
used tx replacement, I would probably start with replacements that don'=
t change the fees and don't count down the lock time field. We can then=
observe whether miners bother changing their software to behave differentl=
y, or whether the inherent utility of the application is enough to convince=
them to play by the default rules. Ideally at least one application made p=
ossible by this feature is a "killer app" - something so useful /=
unique / compelling that people want to obtain Bitcoin just to use it. If =
someone can find such an app, then rational miners should want tx replaceme=
nt to work as reliably as possible because it boosts the value of their ear=
nings.</div>
<div style><br></div><div style>There are some other misc details - reactiv=
ation requires that we bump the protocol version and start relaying non-fin=
al transactions to new nodes again. Those nodes should relay replacements b=
ut not let them enter wallets unless/until the wallet software itself can h=
andle them better, for instance, by communicating via APIs anticipated conf=
irmation times. This is something for individual wallet APIs to handle on t=
heir own, and just ignoring non-final transactions is a perfectly workable =
approach for Bitcoin-Qt.</div>
</div>
--089e012280f22ca3f504da8b6588--
|
