From: Prayank <prayank@tutanota•de>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fee estimates and RBF
Date: Thu, 6 May 2021 03:57:59 +0200 (CEST) [thread overview]
Message-ID: <MZzOKmO--3-2@tutanota.de> (raw)
In-Reply-To: <FD5iXWFzOy1VYbksNsxzhBg-NGiiedTutilM0qpo4jqU15BAjhaZ4hQSqUTJATW8Fjk2kOzKPoGNgZVRIppZlHf1d_7wcYOu9vZIEZ1-x9U=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 3196 bytes --]
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 ZmnSCPxj@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
>
[-- Attachment #2: Type: text/html, Size: 4096 bytes --]
next prev parent reply other threads:[~2021-05-06 1:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-30 20:28 Prayank
2021-05-01 0:11 ` Jeremy
2021-05-01 16:59 ` Prayank
2021-05-03 4:02 ` ZmnSCPxj
2021-05-06 1:57 ` Prayank [this message]
2021-05-14 10:05 Prayank
2021-05-18 13:10 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MZzOKmO--3-2@tutanota.de \
--to=prayank@tutanota$(echo .)de \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox