Good morning ZmnSCPxj,
Thanks for your response. I agree there are few exceptions:
1.Unconfirmed output can be spent resulting in conflict with RBF
2.Race condition and mining pool may include old transaction with low fee
I am trying few things related to RBF and handling such exceptions, will share
if I find anything interesting.
--
Prayank
May 3, 2021, 09:32 by zmnsc...@protonmail.com:
> Good morning Prayank,
>
> I believe a "true" full-RBF wallet should be what every onchain wallet
> aspires to.
>
> However, I think a lot of the effort necessary here has to do with sheer
> engineering issues.
>
> For example, if you think "RBF does not exist", you can do things like:
>
> * Spend an unconfirmed input from a third party.
> * This is not actually safe since an unconfirmed tx might have a conflicting
> transaction get confirmed, but a lot of onchain wallets support this for
> non-RBF unconfirmed inputs because 99.9% of the time this never happens.
> * When you spend from a (confirmed or unconfirmed) input, delete it from your
> db forever (because you do not have to worry about alternate transactions
> spending the same input).
> * This simplifies db design, you do not have to keep track of states like
> "has been spent but tx is not confirmed yet", "has two different alternate
> transactions spending it that have not confirmed", "is on a transaction that
> is not confirmed and therefore this input might disappear completely" etc.
>
> In particular, if we want a "true" full-RBF wallet:
>
> * Suppose the user wants to spend some amount to address A.
> * The user imposes a limit on up to how much to spend on fees to have this
> spend happen.
> * The wallet optimistically creates a low-fee send transaction.
> * After some time, the wallet bumps up the fee by creating a new transaction.
> * The wallet keeps bumping up, up to the designated limit, the longer the
> transaction is not confirmed.
>
> Of note is that there is a *race condition* in the above case.
> When the wallet is bumping up and constructing a new transaction with higher
> fee, a miner could find a new block that has the old transaction with lower
> fee.
>
> Now consider the subsequent user story.
>
> * After some time, the user wants to spend another amount to address B.
> * Again the user imposes a limit on how much to spend on fees to have this
> spend happen.
> * The wallet RBFs the existing transaction to include the spend to address B.
>
> Again, a race condition can occur --- while the wallet is feebumping a new
> transaction that includes the new output, a random miner can find a new block
> that includes the old transaction.
>
> Thus, the wallet really needs to keep track of any "pending spends" and
> correlate them with actual transactions.
>
> Further, of course it is convenient to be able to spend money even while it
> is unconfirmed.
> But the sender of the unconfirmed input might be using the same software as
> this wallet as well, meaning that the actual transaction output might change
> as the original spender keeps fee-bumping it over time.
>
> I confess I have not been thinking of this as well as I should have.
>
> Regards,
> ZmnSCPxj
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
