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; 
MIME-Version: 1.0
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Precedence: list

--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 &lt;<a href=3D"mailto:pete=
@petertodd.org">pete@petertodd.org</a>&gt; 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 &lt;<a href=3D"javasc=
ript:;" onclick=3D"_e(event, &#39;cvml&#39;, &#39;elombrozo@gmail.com&#39;)=
">elombrozo@gmail.com</a>&gt; wrote:<br>
&gt;In case it wasn&#39;t clear in my earlier post, there&#39;s of course a=
 third<br>
&gt;possibility - namely, some outputs are kept but not all. Here, it is<br=
>
&gt;generally impossible to tell whether the motivation was fee<br>
&gt;replacement,<br>
&gt;output replacement, or both. My proposal is to always treat these<br>
&gt;instances<br>
&gt;as output replacement and punish the sender. The sender needs to make<b=
r>
&gt;it<br>
&gt;unambiguously clear it&#39;s only a fee replacement by creating a new<b=
r>
&gt;transaction that produces an output with the desired extra fee and then=
<br>
&gt;adding an input that spends it to the original transaction.<br>
<br>
That&#39;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&#39;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&#39;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&#39;t a negative.<br>
<br></blockquote><div><br></div><div>I think you&#39;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--