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
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <allen.piscitello@gmail.com>) id 1YLzjQ-0007AN-Vm
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 19:47:24 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.174 as permitted sender)
client-ip=209.85.212.174;
envelope-from=allen.piscitello@gmail.com;
helo=mail-wi0-f174.google.com;
Received: from mail-wi0-f174.google.com ([209.85.212.174])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YLzjL-0007XS-OO
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 19:47:24 +0000
Received: by mail-wi0-f174.google.com with SMTP id em10so7069834wid.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Feb 2015 11:47:13 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.3.40 with SMTP id 8mr10938931wjz.98.1423770432959; Thu,
12 Feb 2015 11:47:12 -0800 (PST)
Received: by 10.194.48.105 with HTTP; Thu, 12 Feb 2015 11:47:12 -0800 (PST)
In-Reply-To: <54DD003E.2060508@riseup.net>
References: <20150212064719.GA6563@savin.petertodd.org>
<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
<CAE28kUQ87jWhq1p6RK1eKEuEP1ERxN_P2SS0=YsFEGAqRyMPLA@mail.gmail.com>
<CANEZrP2H2T2QFZceCc=YzwwiApJy7kY7FN0LoAZODGbW12SYsw@mail.gmail.com>
<CAE28kURa8g3YTPi-GHKAt4v0csxXe=QhGhV3aQcDZGSr=Lb7RQ@mail.gmail.com>
<CANEZrP2hAUsRfeXUo-DLiiRmG5uJcwFuP4=o1S6Fb7ts5Ud=bw@mail.gmail.com>
<CADJgMztrzMh8=Y6SD-JV1hpTTbGB8Y2u=59bQhGtF6h3+Ei_Ew@mail.gmail.com>
<356E7F6E-300A-4127-9885-2183FB1DE447@gmail.com>
<54DCECE4.3020802@riseup.net>
<CAJfRnm4OBEJPW-6CiY5fQ1kUYppDnTtZfLF_YpBEaB8ovzx9og@mail.gmail.com>
<54DCFBB5.3080202@gmail.com> <54DD003E.2060508@riseup.net>
Date: Thu, 12 Feb 2015 13:47:12 -0600
Message-ID: <CAJfRnm5d2WcZw3eRjN-cLajwTM0iF_o7OCPc+dkv+s-p3e9nLg@mail.gmail.com>
From: Allen Piscitello <allen.piscitello@gmail.com>
To: Justus Ranvier <justusranvier@riseup.net>
Content-Type: multipart/alternative; boundary=047d7b3a8394e602dc050ee9623e
X-Spam-Score: -0.6 (/)
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
(allen.piscitello[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1YLzjL-0007XS-OO
Cc: Bitcoin Development <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 19:47:25 -0000
--047d7b3a8394e602dc050ee9623e
Content-Type: text/plain; charset=UTF-8
Nothing will stop that. Bitcoin needs to deal with those issues, not stick
our heads in the sand and pretend they don't exist out of benevolence.
This isn't a pet solution, but the rules of the protocol and what is
realistically possible given the nature of distributed consensus. Relying
on altruism is a recipe for failure.
On Thu, Feb 12, 2015 at 1:34 PM, Justus Ranvier <justusranvier@riseup.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/12/2015 07:15 PM, Alan Reiner wrote:
> > I'll add fuel to the fire here, and express that I believe that
> > replace-by-fee is good in the long-term. Peter is not breaking
> > the zero-conf, it was already broken, and not admitting it creates
> > a false sense of security. I don't want to see systems that are
> > built on the assumption that zero-conf tx are safe solely because
> > it has always appeared safe. You can argue about rational miner
> > behaviors all day, but in a decentralized system you have no idea
> > what miners consider rational, or speculate about their incentives.
> >
> As noted elsewhere in the thread, there are two problems with this
> analysis:
>
> 1. It asserts that zero-confirmation transactions are in a binary
> state of safe/broken instead of recognizing that relying on them is a
> non-binary risk analysis on the part of a merchant.
>
> 2. Assumptions about what is profitable for miners are based on all
> miners having short time horizons for calculating profits.
>
> In addition, I'll add that there is an assumption that honest actors
> can not alter their behavior in response to changing conditions.
>
> Since scorched-earth solutions to problems are apparently acceptable
> now, what would stop more honest node operators from patching their
> nodes to blacklist any peer that relays replace-by-fee transactions,
> and maybe even publish an IP address list of those peers?
>
> Punishing Bitcoin users for not adopting somebody's pet solution to a
> problem neither responsible nor ethical.
>
> Child-pays-for-parent allows for stuck transactions to be cleared from
> the mempool, and allows recipients of zero-conf transactions to adjust
> their risk exposure as much or as little as they like.
>
> It's a solution that gives Bitcoin users more freedom, instead of
> trying to coerce them into pre-determined directions.
>
> - --
> Support online privacy by using email encryption whenever possible.
> Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt
> vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO
> hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99
> kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/
> F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt
> P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh
> pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5
> sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f
> b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd
> j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL
> LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0
> F9dKdL5zCGofvU/U5BVq
> =kEMr
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> 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
>
>
--047d7b3a8394e602dc050ee9623e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Nothing will stop that.=C2=A0 Bitcoin needs to deal with t=
hose issues, not stick our heads in the sand and pretend they don't exi=
st out of benevolence.=C2=A0 This isn't a pet solution, but the rules o=
f the protocol and what is realistically possible given the nature of distr=
ibuted consensus.=C2=A0 Relying on altruism is a recipe for failure.</div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Feb 12, 20=
15 at 1:34 PM, Justus Ranvier <span dir=3D"ltr"><<a href=3D"mailto:justu=
sranvier@riseup.net" target=3D"_blank">justusranvier@riseup.net</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">-----BEGIN PG=
P SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
</span><span class=3D"">On 02/12/2015 07:15 PM, Alan Reiner wrote:<br>
> I'll add fuel to the fire here, and express that I believe that<br=
>
> replace-by-fee is good in the long-term.=C2=A0 Peter is not breaking<b=
r>
> the zero-conf, it was already broken, and not admitting it creates<br>
> a false sense of security.=C2=A0 I don't want to see systems that =
are<br>
> built on the assumption that zero-conf tx are safe solely because<br>
> it has always appeared safe.=C2=A0 You can argue about rational miner<=
br>
> behaviors all day, but in a decentralized system you have no idea<br>
> what miners consider rational, or speculate about their incentives.<br=
>
><br>
</span>As noted elsewhere in the thread, there are two problems with this<b=
r>
analysis:<br>
<br>
1. It asserts that zero-confirmation transactions are in a binary<br>
state of safe/broken instead of recognizing that relying on them is a<br>
non-binary risk analysis on the part of a merchant.<br>
<br>
2. Assumptions about what is profitable for miners are based on all<br>
miners having short time horizons for calculating profits.<br>
<br>
In addition, I'll add that there is an assumption that honest actors<br=
>
can not alter their behavior in response to changing conditions.<br>
<br>
Since scorched-earth solutions to problems are apparently acceptable<br>
now, what would stop more honest node operators from patching their<br>
nodes to blacklist any peer that relays replace-by-fee transactions,<br>
and maybe even publish an IP address list of those peers?<br>
<br>
Punishing Bitcoin users for not adopting somebody's pet solution to a<b=
r>
problem neither responsible nor ethical.<br>
<br>
Child-pays-for-parent allows for stuck transactions to be cleared from<br>
the mempool, and allows recipients of zero-conf transactions to adjust<br>
their risk exposure as much or as little as they like.<br>
<br>
It's a solution that gives Bitcoin users more freedom, instead of<br>
trying to coerce them into pre-determined directions.<br>
<span class=3D""><br>
- --<br>
Support online privacy by using email encryption whenever possible.<br>
Learn how here: <a href=3D"http://www.youtube.com/watch?v=3DbakOKJFtB-k" ta=
rget=3D"_blank">http://www.youtube.com/watch?v=3DbakOKJFtB-k</a><br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
</span>iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt<br>
vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO<br>
hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99<br>
kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/<br>
F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt<br>
P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh<br>
pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5<br>
sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f<br>
b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd<br>
j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL<br>
LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0<br>
F9dKdL5zCGofvU/U5BVq<br>
=3DkEMr<br>
-----END PGP SIGNATURE-----<br>
<br>-----------------------------------------------------------------------=
-------<br>
Dive into the World of Parallel Programming. The Go Parallel Website,<br>
sponsored by Intel and developed in partnership with Slashdot Media, is you=
r<br>
hub for all things parallel software development, from weekly thought<br>
leadership blogs to news, videos, case studies, tutorials and more. Take a<=
br>
look and join the conversation now. <a href=3D"http://goparallel.sourceforg=
e.net/" target=3D"_blank">http://goparallel.sourceforge.net/</a><br>_______=
________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--047d7b3a8394e602dc050ee9623e--
|
