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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <elombrozo@gmail.com>) id 1YPfy4-0008U6-B1
for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 23:29:44 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.171 as permitted sender)
client-ip=209.85.217.171; envelope-from=elombrozo@gmail.com;
helo=mail-lb0-f171.google.com;
Received: from mail-lb0-f171.google.com ([209.85.217.171])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YPfy3-0005t1-58
for bitcoin-development@lists.sourceforge.net;
Sun, 22 Feb 2015 23:29:44 +0000
Received: by lbvn10 with SMTP id n10so15466631lbv.6
for <bitcoin-development@lists.sourceforge.net>;
Sun, 22 Feb 2015 15:29:36 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.1.1 with SMTP id 1mr7247036lai.63.1424647776737; Sun, 22
Feb 2015 15:29:36 -0800 (PST)
Received: by 10.112.201.67 with HTTP; Sun, 22 Feb 2015 15:29:36 -0800 (PST)
In-Reply-To: <F357F1A0-BE23-464B-8A14-6A205D440092@petertodd.org>
References: <20150212064719.GA6563@savin.petertodd.org>
<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
<CAJHLa0PkzG44JpuQoHVLUU8SR55LaJf5AwG=a7AjK2u7TAveOQ@mail.gmail.com>
<20150215212512.GR14804@nl.grid.coop> <54E11248.6090401@gmail.com>
<20150219085604.GT14804@nl.grid.coop>
<CABm2gDorEFNzzHH2bxpo6miv1H0RUhL9uAYX6gg2aW0wB1QDbw@mail.gmail.com>
<CAOG=w-uJFobZtkd8OoPnOJC3uqCOwjsqyfNWJTg3j3sJQn+wXQ@mail.gmail.com>
<CAJHLa0M4Tc7kiQVNmBfMBvSqFyrmHXdaNh7mF+crAdME5FUWHg@mail.gmail.com>
<CABm2gDpMagWHsBn1t_oLO2bESgD2NUpefYw-gePFaBCNmpXviQ@mail.gmail.com>
<CAJHLa0ObR32wg7TEJ2XHgZ=9=Z+yFsXjF3JCz+4d5mdp1=xu4Q@mail.gmail.com>
<CABr1YTcr9C4uoXFfTJ6BEGHaw1a3dV_J=SE=fZbbpZRdTtD8tw@mail.gmail.com>
<CABr1YTefbYqqtx0fSm_GBASxE2Za9EGWOPM2A5X4PRxbVemyiw@mail.gmail.com>
<CABr1YTfZDSpyMLNi2pYORh01f_G3tL0rcw2Zo0m_P4-vjsJfmQ@mail.gmail.com>
<F357F1A0-BE23-464B-8A14-6A205D440092@petertodd.org>
Date: Sun, 22 Feb 2015 15:29:36 -0800
Message-ID: <CABr1YTdrkJfFNua5cq9mFMo8-onB220xSH=9keUCjcvNVsZiLA@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e013c6af0a9a20d050fb5a85f
X-Spam-Score: 0.3 (/)
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
(elombrozo[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
0.9 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YPfy3-0005t1-58
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: Sun, 22 Feb 2015 23:29:44 -0000
--089e013c6af0a9a20d050fb5a85f
Content-Type: text/plain; charset=UTF-8
On Sunday, February 22, 2015, Peter Todd <pete@petertodd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo <elombrozo@gmail.com
> <javascript:;>> wrote:
> >In case it wasn't clear in my earlier post, there's of course a third
> >possibility - namely, some outputs are kept but not all. Here, it is
> >generally impossible to tell whether the motivation was fee
> >replacement,
> >output replacement, or both. My proposal is to always treat these
> >instances
> >as output replacement and punish the sender. The sender needs to make
> >it
> >unambiguously clear it's only a fee replacement by creating a new
> >transaction that produces an output with the desired extra fee and then
> >adding an input that spends it to the original transaction.
>
> That's a really old idea - I proposed it about two years ago. The optimal
> way is to allow any txout to be replaced with one with an equal or greater
> nValue and same scriptPubKey, as well as additional txouts added.
> (obviously so long as none are removed)
>
>
That won't work because in general it is impossible to know which
transaction is the original. Did we add outputs to transaction A? Or remove
outputs from transaction B?
> Alas, there's lots of situations where this restricts you from doing
> useful things, for instance collapsing multiple payments into one by
> repeated updating to reduce tx size. Equally the benefit is marginal at
> best given how insecure unconfirmed transactions are - breaking what is
> already broken isn't a negative.
>
>
I think you're unnecessarily complicating use cases.
As for 0-conf security, there are instances where 0-conf transactions make
a lot of sense - i.e. paying for utilities, ISP, web hosting, or other such
services which could be immediately shut off upon detection of a
double-spend.
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6d9O
> AAoJEMCF8hzn9LncUOUH/3yY4wDyFSkL9o6GsntphAmJSN35wVAlxPxBmNTk0KR3
> YfVhY1cTBIXKqsfqz/n1Sqn264aMzW48xUTtDF2xLzJc1FY5qTBw7zbVrZgYIvvr
> GEakZW1SxLXsfSs2Onutl0WQWi8EMfxEXEPQIiiWy9mq4EtwxMOcDviETycu6Wmn
> pmHY00Lo8jhLUyuIkzIZrZetEtWz1VtovbJO5l7WfmLgPWzW+zERPY/pGGioqdiJ
> NOEaocQ+2+OZjyx3MJ4YAch5ZtfB45g+NBm8WyeGpBgxzK3ZIpmyZIQ6HqZr0gpl
> NMUQh6Sbi8WaTEp6hoYTiEfZcEy4IDPg6f0DEW71BPs=
> =1vbN
> -----END PGP SIGNATURE-----
>
>
--089e013c6af0a9a20d050fb5a85f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, February 22, 2015, Peter Todd <<a href=3D"mailto:pete=
@petertodd.org">pete@petertodd.org</a>> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
<br>
<br>
On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo <<a href=3D"javasc=
ript:;" onclick=3D"_e(event, 'cvml', 'elombrozo@gmail.com')=
">elombrozo@gmail.com</a>> wrote:<br>
>In case it wasn't clear in my earlier post, there's of course a=
third<br>
>possibility - namely, some outputs are kept but not all. Here, it is<br=
>
>generally impossible to tell whether the motivation was fee<br>
>replacement,<br>
>output replacement, or both. My proposal is to always treat these<br>
>instances<br>
>as output replacement and punish the sender. The sender needs to make<b=
r>
>it<br>
>unambiguously clear it's only a fee replacement by creating a new<b=
r>
>transaction that produces an output with the desired extra fee and then=
<br>
>adding an input that spends it to the original transaction.<br>
<br>
That's a really old idea - I proposed it about two years ago. The optim=
al way is to allow any txout to be replaced with one with an equal or great=
er nValue and same scriptPubKey, as well as additional txouts added. (obvio=
usly so long as none are removed)<br>
<br></blockquote><div><br></div><div>That won't work because in general=
it is impossible to know which transaction is the original. Did we add out=
puts to transaction A? Or remove outputs from transaction B?</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
Alas, there's lots of situations where this restricts you from doing us=
eful things, for instance collapsing multiple payments into one by repeated=
updating to reduce tx size. Equally the benefit is marginal at best given =
how insecure unconfirmed transactions are - breaking what is already broken=
isn't a negative.<br>
<br></blockquote><div><br></div><div>I think you're unnecessarily compl=
icating use cases.</div><div><br></div><div>As for 0-conf security, there a=
re instances where 0-conf transactions make a lot of sense - i.e. paying fo=
r utilities, ISP, web hosting, or other such services which could be immedi=
ately shut off upon detection of a double-spend.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
-----BEGIN PGP SIGNATURE-----<br>
<br>
iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6d9O<br>
AAoJEMCF8hzn9LncUOUH/3yY4wDyFSkL9o6GsntphAmJSN35wVAlxPxBmNTk0KR3<br>
YfVhY1cTBIXKqsfqz/n1Sqn264aMzW48xUTtDF2xLzJc1FY5qTBw7zbVrZgYIvvr<br>
GEakZW1SxLXsfSs2Onutl0WQWi8EMfxEXEPQIiiWy9mq4EtwxMOcDviETycu6Wmn<br>
pmHY00Lo8jhLUyuIkzIZrZetEtWz1VtovbJO5l7WfmLgPWzW+zERPY/pGGioqdiJ<br>
NOEaocQ+2+OZjyx3MJ4YAch5ZtfB45g+NBm8WyeGpBgxzK3ZIpmyZIQ6HqZr0gpl<br>
NMUQh6Sbi8WaTEp6hoYTiEfZcEy4IDPg6f0DEW71BPs=3D<br>
=3D1vbN<br>
-----END PGP SIGNATURE-----<br>
<br>
</blockquote>
--089e013c6af0a9a20d050fb5a85f--
|
