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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <oleganza@gmail.com>) id 1YLxVS-0008DU-19
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 17:24:50 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.175 as permitted sender)
client-ip=209.85.212.175; envelope-from=oleganza@gmail.com;
helo=mail-wi0-f175.google.com;
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YLxVQ-0001xD-UK
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 17:24:50 +0000
Received: by mail-wi0-f175.google.com with SMTP id r20so6075892wiv.2
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Feb 2015 09:24:42 -0800 (PST)
X-Received: by 10.194.133.101 with SMTP id pb5mr10419770wjb.40.1423761882276;
Thu, 12 Feb 2015 09:24:42 -0800 (PST)
Received: from ?IPv6:2a01:e35:8a2c:a630:28c0:1758:7e4d:9520?
([2a01:e35:8a2c:a630:28c0:1758:7e4d:9520])
by mx.google.com with ESMTPSA id hn2sm6539058wjc.5.2015.02.12.09.24.41
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 12 Feb 2015 09:24:41 -0800 (PST)
Content-Type: multipart/alternative;
boundary="Apple-Mail=_DD1E8954-3242-433F-AFF8-C3FBA702C621"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Oleg Andreev <oleganza@gmail.com>
In-Reply-To: <CADJgMztrzMh8=Y6SD-JV1hpTTbGB8Y2u=59bQhGtF6h3+Ei_Ew@mail.gmail.com>
Date: Thu, 12 Feb 2015 18:24:40 +0100
Message-Id: <356E7F6E-300A-4127-9885-2183FB1DE447@gmail.com>
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>
To: Btc Drak <btcdrak@gmail.com>
X-Mailer: Apple Mail (2.1993)
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
(oleganza[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: 1YLxVQ-0001xD-UK
Cc: Bitcoin Dev <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 17:24:50 -0000
--Apple-Mail=_DD1E8954-3242-433F-AFF8-C3FBA702C621
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
> I think that is a misdirection on your part. The point of =
replace-by-fee is to make 0-confirms reliably unreliable. Currently =
people can "get away" with 0-confirms but it's only because most people =
arent actively double spending, and when they do it is for higher value =
targets. Double spend attacks are happening a lot more frequently than =
is being admitted here, according to Peter from work with various =
clients.=20
>=20
> Like single address reuse, people have gotten used to something which =
is bad. Generally accepting 0-conf is also a bad idea(tm) and instant =
confirmation solutions should be sought elsewhere. There are already =
interesting solutions and concepts: greenaddress for example, and =
CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than =
supporting and promoting risky 0-confirms, we need to spend time on =
better alternative solutions that will work for everyone and not during =
the honeymoon phase where attackers are fewer.
Here's value-free assessment of the issue here:
1. Zero-conf txs are unsafe.
2. We'd all want to have a safer instant payments solution if possible.
3. As a social artifact, today zeroconf txs happen to work for some =
people in some situations.
4. Replace-by-fee will break #3 and probably hasten development of #2.
The discussion boils down to whether we should make #2 happen sooner by =
breaking remnants of #3 sooner.
I personally would rather not break anything, but work as fast as =
possible on #2 so no matter when and how #3 becomes utterly broken, we =
have a better solution. This implies that I also don't want to waste =
time debating with Peter Todd and others. I want to be ready with a =
working tool when zeroconf completely fails (with that patch or for some =
other reasons).
TL;DR: those who are against the patch are better off building a =
decentralized clearing network rather than wasting time on debates. When =
we have such network, we might all want this patch to be used for all =
the reasons Peter has already outlined.
--Apple-Mail=_DD1E8954-3242-433F-AFF8-C3FBA702C621
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D""><span style=3D"font-family: HelveticaNeue;" class=3D"">I =
think that is a misdirection on your part. The point of replace-by-fee =
is to make 0-confirms reliably unreliable. Currently people can "get =
away" with 0-confirms but it's only because most people arent actively =
double spending, and when they do it is for higher value targets. Double =
spend attacks</span> <i class=3D"" style=3D"font-family: =
HelveticaNeue;">are</i> <span style=3D"font-family: HelveticaNeue;" =
class=3D"">happening a lot more frequently than is being admitted here, =
according to Peter from work with various =
clients. </span></div><div class=3D""><div style=3D"font-family: =
HelveticaNeue; font-size: 14px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;" class=3D""><br class=3D""></div><div=
style=3D"font-family: HelveticaNeue; font-size: 14px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">Like =
single address reuse, people have gotten used to something which is bad. =
Generally accepting 0-conf is also a bad idea(tm) and instant =
confirmation solutions should be sought elsewhere. There are already =
interesting solutions and concepts: greenaddress for example, and =
CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than =
supporting and promoting risky 0-confirms, we need to spend time on =
better alternative solutions that will work for everyone and not during =
the honeymoon phase where attackers are =
fewer.</div></div></blockquote></div><br class=3D""><div class=3D"">Here's=
value-free assessment of the issue here:</div><div class=3D""><br =
class=3D""></div><div class=3D"">1. Zero-conf txs are unsafe.</div><div =
class=3D"">2. We'd all want to have a safer instant payments solution if =
possible.</div><div class=3D"">3. As a social artifact, today zeroconf =
txs happen to work for some people in some situations.</div><div =
class=3D"">4. Replace-by-fee will break #3 and probably hasten =
development of #2.</div><div class=3D""><br class=3D""></div><div =
class=3D"">The discussion boils down to whether we should make #2 happen =
sooner by breaking remnants of #3 sooner.</div><div class=3D""><br =
class=3D""></div><div class=3D"">I personally would rather not break =
anything, but work as fast as possible on #2 so no matter when and how =
#3 becomes utterly broken, we have a better solution. This implies that =
I also don't want to waste time debating with Peter Todd and others. I =
want to be ready with a working tool when zeroconf completely fails =
(with that patch or for some other reasons).</div><div class=3D""><br =
class=3D""></div><div class=3D"">TL;DR: those who are against the patch =
are better off building a decentralized clearing network rather than =
wasting time on debates. When we have such network, we might all want =
this patch to be used for all the reasons Peter has already =
outlined.</div><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div></body></html>=
--Apple-Mail=_DD1E8954-3242-433F-AFF8-C3FBA702C621--
|
