[Bitcoin-development] First-Seen-Safe Replace-by-Fee

Danny Thorpe danny.thorpe at gmail.com
Tue May 26 22:09:35 UTC 2015


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 at 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....
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150526/ac340045/attachment.html>


More information about the bitcoin-dev mailing list