Why Nostr? What is Njump?
2023-06-07 15:35:42
in reply to

Danny Thorpe [ARCHIVE] on Nostr: šŸ“… Original date posted:2015-05-26 šŸ“ Original message:Thanks for the ...

šŸ“… Original date posted:2015-05-26
šŸ“ Original message: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>;
Author Public Key
npub1q5sgcakfxhw3ya93tvnpqeacvf32p6lw70hke53rkjnf9lhw9w8s43ps87