Date: Mon, 03 May 2021 04:02:07 +0000
To: Prayank <prayank@tutanota.de>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <FD5iXWFzOy1VYbksNsxzhBg-NGiiedTutilM0qpo4jqU15BAjhaZ4hQSqUTJATW8Fjk2kOzKPoGNgZVRIppZlHf1d_7wcYOu9vZIEZ1-x9U=@protonmail.com>
In-Reply-To: <MZZT0_o--3-2@tutanota.de>
References: <MZZT0_o--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Fee estimates and RBF
Precedence: list

Good morning Prayank,

I believe a "true" full-RBF wallet should be what every onchain wallet aspi=
res to.

However, I think a lot of the effort necessary here has to do with sheer en=
gineering 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 conflict=
ing transaction get confirmed, but a lot of onchain wallets support this fo=
r 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 yo=
ur db forever (because you do not have to worry about alternate transaction=
s 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 th=
at is not confirmed and therefore this input might disappear completely" et=
c.

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 thi=
s spend happen.
* The wallet optimistically creates a low-fee send transaction.
* After some time, the wallet bumps up the fee by creating a new transactio=
n.
  * 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 highe=
r fee, a miner could find a new block that has the old transaction with low=
er 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 thi=
s 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 blo=
ck that includes the old transaction.

Thus, the wallet really needs to keep track of any "pending spends" and cor=
relate 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 chan=
ge 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