Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.218.42 as permitted sender)
	client-ip=209.85.218.42; envelope-from=danny.thorpe@gmail.com;
	helo=mail-oi0-f42.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAPg+sBisM6FVEDo0uqgvFwVxB71r_f4T5bAr91esv9r78wf6wA@mail.gmail.com>
References: <20150526051305.GA23502@savin.petertodd.org>
	<CAJN5wHXRMfZigtgJ4JTKqRMkoQgkZ-d8sZ5rkpspqySwFEQEKg@mail.gmail.com>
	<CAPg+sBisM6FVEDo0uqgvFwVxB71r_f4T5bAr91esv9r78wf6wA@mail.gmail.com>
Date: Tue, 26 May 2015 15:09:35 -0700
Message-ID: <CAJN5wHVq67m-fDZLwkHhjtsoDdqP70DKMziuM7RueazQ=+tdhg@mail.gmail.com>
From: Danny Thorpe <danny.thorpe@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11331258b402e705170361b4
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
Precedence: list

--001a11331258b402e705170361b4
Content-Type: text/plain; charset=UTF-8

Thanks for the clarification.

So, since RBF applies only to pending transactions in the mempool awaiting
incorporation into a block, there is a window of opportunity in which the
pending tx is incorporated into a block at the same time that the spender
is constructing and publishing a replacement for that pending tx.

The replacement transaction would be rejected by the peer network as a
double spend because it conflicts with the now confirmed original tx, and
the spender will have to go back and create a new stand-alone transaction
to accomplish what they hoped to do with an RBF replacement.

So an implementation that wishes to take advantage of RBF will still need
to have a "plan B" implementation path to handle the corner case of a
replacement tx being rejected as a double spend.

Is this correct?

I'm just trying to get my head around the implementation cost vs benefit of
RBF in the context of my applications.

Thanks,
-Danny

On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:

> It's just a mempool policy rule.
>
> Allowing the contents of blocks to change (other than by mining a
> competing chain) would be pretty much the largest possible change to
> Bitcoin's design....
>

--001a11331258b402e705170361b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the clarification.<div><br></div><div>So, since=
 RBF applies only to pending transactions in the mempool awaiting incorpora=
tion into a block, there is a window of opportunity in which the pending tx=
 is incorporated into a block at the same time that the spender is construc=
ting and publishing a replacement for that pending tx.=C2=A0</div><div><br>=
</div><div>The replacement transaction would be rejected by the peer networ=
k as a double spend because it conflicts with the now confirmed original tx=
, and the spender will have to go back and create a new stand-alone transac=
tion to accomplish what they hoped to do with an RBF replacement.</div><div=
><br></div><div>So an implementation that wishes to take advantage of RBF w=
ill still need to have a &quot;plan B&quot; implementation path to handle t=
he corner case of a replacement tx being rejected as a double spend.</div><=
div><br></div><div>Is this correct? =C2=A0</div><div><br></div><div>I&#39;m=
 just trying to get my head around the implementation cost vs benefit of RB=
F in the context of my applications.</div><div><br></div><div>Thanks,</div>=
<div>-Danny</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille <span dir=3D"ltr">&lt;=
<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=
=3D"ltr">It&#39;s just a mempool policy rule.</p>
<p dir=3D"ltr">Allowing the contents of blocks to change (other than by min=
ing a competing chain) would be pretty much the largest possible change to =
Bitcoin&#39;s design....</p>
</blockquote></div><br></div>

--001a11331258b402e705170361b4--