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
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <krellan@krellan.net>) id 1YM1mi-0000GQ-H6
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 21:58:56 +0000
X-ACL-Warn:
Received: from transmat.krellan.net ([70.36.220.56] helo=tardis.krellan.net)
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YM1mg-0003f6-7h
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 21:58:56 +0000
Received: from [IPv6:2001:470:1f05:12fe:21f:f3ff:fe55:c215] (unknown
[IPv6:2001:470:1f05:12fe:21f:f3ff:fe55:c215])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by tardis.krellan.net (Postfix) with ESMTPSA id ADBF8400C9F;
Thu, 12 Feb 2015 13:40:50 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Josh Lehan <krellan@krellan.net>
In-Reply-To: <20150212064719.GA6563@savin.petertodd.org>
Date: Thu, 12 Feb 2015 13:40:48 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <13DBC715-3EFB-42DB-9003-C7AA72D7BCC6@krellan.net>
References: <20150212064719.GA6563@savin.petertodd.org>
To: Peter Todd <pete@petertodd.org>
X-Mailer: Apple Mail (2.2070.6)
X-Spam-Score: -0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-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: 1YM1mg-0003f6-7h
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: Thu, 12 Feb 2015 21:58:56 -0000
Probably out of my league, but I will respond here anyway.
I am in favor of replace-by-fee, but only if it were to be applied to a =
very limited subset of transactions: namely, transactions that seek to =
supplement, not replace, the original transaction.
In other words, a replacement transaction would only be accepted if it =
were adding additional value (additional transaction inputs and/or =
outputs). Otherwise, the original transaction would stand. Reducing =
any of the promised outputs, or diverting them to some other recipient, =
would not be allowed.
This would solve the problem of a stuck transaction: a transaction that =
is taking seemingly forever to confirm, because one forgot to pay the =
miner=E2=80=99s fee, something that happened to me once.
Stuck transactions are bad, both for the recipient (they aren=E2=80=99t =
getting paid) and the sender (some of their funds are still tied up, =
because change from that transaction has not returned yet).
With replace-by-fee, the sender of a transaction can send it again, with =
additional inputs (to pay more miner=E2=80=99s fees) and additional =
outputs (to receive the change, if any is desired, from those inputs). =
So, now the sender is self-empowered to =E2=80=9Cshove through=E2=80=9D =
their stuck transaction, by voluntarily choosing to pay more for it, a =
market-driven solution to the problem.
There are really good reasons to not allow replace-by-fee as a general =
policy that can apply to all transactions, as others have already =
mentioned. However, I still believe the idea has merit, for this =
special limited case of supplementing a transaction.
Josh Lehan
> On Feb 11, 2015, at 22:47, Peter Todd <pete@petertodd.org> wrote:
>=20
> My replace-by-fee patch is now available for the v0.10.0rc4 release:
>=20
> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4
>=20
> Along with demo scripts of the functionality:
>=20
> https://github.com/petertodd/replace-by-fee-tools
>=20
> New to this version is a comprehensive set of unittests under
> qa/replace-by-fee
>=20
> Additionally the preferential peering support now preferentially peers
> with Bitcoin XT=C2=B9 nodes that support Andresen/Harding's =
double-spend
> relaying=C2=B2 patch. While Bitcoin XT nodes don't accept =
double-spends into
> their mempool, they do relay them perfectly well and thus are an asset
> to those doing replace-by-fee mining.=C2=B3
>=20
> I've had a number of requests from miners for a version of
> replace-by-fee against Luke-Jr's Eligius patches=E2=81=B4; I'll be =
also
> releasing that shortly once this release has undergone some more
> testing.
>=20
>=20
> What's replace-by-fee?
> ----------------------
>=20
> Currently most Bitcoin nodes accept the first transaction they see
> spending an output to the mempool; all later transactions are =
rejected.
> Replace-by-fee changes this behavior to accept the transaction paying
> the highest fee, both absolutely, and in terms of fee-per-KB. Replaced
> children are also considered - a chain of transactions is only =
replaced
> if the replacement has a higher fee than the sum of all replaced
> transactions.
>=20
> Doing this aligns standard node behavior with miner incentives: earn =
the
> most amount of money per block. It also makes for a more efficient
> transaction fee marketplace, as transactions that are "stuck" due to =
bad
> fee estimates can be "unstuck" by double-spending them with higher
> paying versions of themselves. With scorched-earth techniques=E2=81=B5 =
it gives
> a path to making zeroconf transactions economically secure by relying =
on
> economic incentives, rather than "honesty" and alturism, in the same =
way
> Bitcoin mining itself relies on incentives rather than "honesty" and
> alturism.
>=20
> Finally for miners adopting replace-by-fee avoids the development of =
an
> ecosystem that relies heavily on large miners punishing smaller ones =
for
> misbehavior, as seen in Harding's proposal=E2=81=B6 that miners =
collectively 51%
> attack miners who include doublespends in their blocks - an =
unavoidable
> consequence of imperfect p2p networking in a decentralized system - or
> even Hearn's proposal=E2=81=B7 that a majority of miners be able to =
vote to
> confiscate the earnings of the minority and redistribute them at will.
>=20
>=20
> Installation
> ------------
>=20
> Once you've compiled the replace-by-fee-v0.10.0rc4 branch just run =
your
> node normally. With -debug logging enabled, you'll see messages like =
the
> following in your ~/.bitcoin/debug.log indicating your node is =
replacing
> transactions with higher-fee paying double-spends:
>=20
> 2015-02-12 05:45:20 replacing tx =
ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with =
c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for =
0.00798 BTC additional fees, -1033 delta bytes
>=20
> Additionally you can tell if you are connected to other replace-by-fee
> nodes, or Bitcoin XT nodes, by examining the service bits advertised =
by
> your peers:
>=20
> $ bitcoin-cli getpeerinfo | grep services | egrep =
'((0000000000000003)|(0000000004000001))'
> "services" : "0000000000000003",
> "services" : "0000000004000001",
> "services" : "0000000004000001",
> "services" : "0000000000000003",
> "services" : "0000000004000001",
> "services" : "0000000004000001",
> "services" : "0000000000000003",
> "services" : "0000000000000003",
>=20
> Replace-by-fee nodes advertise service bit 26 from the experimental =
use
> range; Bitcoin XT nodes advertise service bit 1 for their getutxos
> support. The code sets aside a certain number of outgoing and incoming
> slots just for double-spend relaying nodes, so as long as everything =
is
> working you're node should be connected to like-minded nodes a within =
30
> minutes or so of starting up.
>=20
> If you *don't* want to advertise the fact that you are running a
> replace-by-fee node, just checkout a slightly earlier commit in git; =
the
> actual mempool changes are separate from the preferential peering
> commits. You can then connect directly to a replace-by-fee node using
> the -addnode command line flag.
>=20
> 1) https://github.com/bitcoinxt/bitcoinxt
> 2) https://github.com/bitcoin/bitcoin/pull/3883
> 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370
> 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP
> 5) =
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/ms=
g05211.html
> 6) =
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg0=
6970.html
> 7) =
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/ms=
g04972.html
>=20
> --=20
> 'peter'[:-1]@petertodd.org
> 000000000000000013c290b77d45d2ea7f9220aedfadfd556ad41b6bd39822f3
> =
--------------------------------------------------------------------------=
----
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, =
is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. =
Take a
> look and join the conversation now. =
http://goparallel.sourceforge.net/________________________________________=
_______
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
