MIME-Version: 1.0
In-Reply-To: <CAJN5wHVq67m-fDZLwkHhjtsoDdqP70DKMziuM7RueazQ=+tdhg@mail.gmail.com>
References: <20150526051305.GA23502@savin.petertodd.org>
	<CAJN5wHXRMfZigtgJ4JTKqRMkoQgkZ-d8sZ5rkpspqySwFEQEKg@mail.gmail.com>
	<CAPg+sBisM6FVEDo0uqgvFwVxB71r_f4T5bAr91esv9r78wf6wA@mail.gmail.com>
	<CAJN5wHVq67m-fDZLwkHhjtsoDdqP70DKMziuM7RueazQ=+tdhg@mail.gmail.com>
Date: Tue, 26 May 2015 23:18:42 +0100
Message-ID: <CALqxMTHq1E3XPggF_-CmWb15rz6VU0HEmbxLutrZ8NCLyQ77sQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Danny Thorpe <danny.thorpe@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
Precedence: list

I think the point is the replacement tx spends the same inputs (plus
additional inputs), so if the original tx is accepted, and your
replacement rejected, thats good news - you dont have to pay the
higher fee, the extra input remains unspent (and can be used later for
other purpose) and the extra change address is unused.

(If you had bundled extra transactions into the replacement, spending
from the additional inputs, then you'll need to resubmit those as a
separate transaction).

(You have to keep in mind re-orgs so for example the original tx could
be put into a block, and then that block could get reorged by another
block that grows into a longer chain with the replacement tx in it (or
vice versa)).

Adam

On 26 May 2015 at 23:09, Danny Thorpe <danny.thorpe@gmail.com> wrote:
> 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....
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>