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.wui...@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
