From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D4A6DC0001 for ; Thu, 6 May 2021 01:58:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id B782B40417 for ; Thu, 6 May 2021 01:58:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.de Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmoATjzzMZKk for ; Thu, 6 May 2021 01:58:02 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) by smtp4.osuosl.org (Postfix) with ESMTPS id 11A244040E for ; Thu, 6 May 2021 01:58:01 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 464A6FBF4B7; Thu, 6 May 2021 01:57:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1620266279; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=7CTwILPy6Zb5CHzR8OdZvnMmSMDAbfUHxsb48mf449c=; b=KEzj8flgnvXz3B+rtJRNC81Oe62ELjpDtzd21ZHaIWJtNvsEn2CAo8N5RBt+K88F BypXo0uFLPL2v7YCReniW2RVvd6EgvvXlovuvYs8RWnCje4WtZ6Y8AKTXthlNlzLFyN Il0ANpl9rSG0/FTqrmqCKXVuj4rqP6yo9ptZkB9XUuDOis7RK/MhAdPm4rzyEwhKQnQ kZ5TzH8XaTsDTVdQs0UjT9U9r8aEQ5qeviZlFk1xR0x0xXyE/Cx2jz4loNtOlXawNts wdz0ECIC9lYeoKkLpCmo4rgfdS4lkcAdS/ndY2XsRPT021Alm4nj5iwUNpGavuyc8sJ wy2HahuAvg== Date: Thu, 6 May 2021 03:57:59 +0200 (CEST) From: Prayank To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_301462_445357612.1620266279269" X-Mailman-Approved-At: Thu, 06 May 2021 08:14:17 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Fee estimates and RBF X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 01:58:04 -0000 ------=_Part_301462_445357612.1620266279269 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good morning ZmnSCPxj, Thanks for your response. I agree there are few exceptions:=C2=A0 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 sh= are if I find anything interesting. --=20 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 as= pires 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 conflic= ting transaction get confirmed, but a lot of onchain wallets support this f= or 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 transacti= ons spending the same input). > * This simplifies db design, you do not have to keep track of states lik= e "has been spent but tx is not confirmed yet", "has two different alternat= e transactions spending it that have not confirmed", "is on a transaction t= hat is not confirmed and therefore this input might disappear completely" e= tc. > > 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 th= is spend happen. > * The wallet optimistically creates a low-fee send transaction. > * After some time, the wallet bumps up the fee by creating a new transact= ion. > * The wallet keeps bumping up, up to the designated limit, the longer th= e 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 hig= her fee, a miner could find a new block that has the old transaction with l= ower 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 th= is spend happen. > * The wallet RBFs the existing transaction to include the spend to addres= s B. > > Again, a race condition can occur --- while the wallet is feebumping a ne= w transaction that includes the new output, a random miner can find a new b= lock that includes the old transaction. > > Thus, the wallet really needs to keep track of any "pending spends" and c= orrelate 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 ch= ange 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 > ------=_Part_301462_445357612.1620266279269 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good morning ZmnSCPxj,

Thanks for your re= sponse. 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 han= dling 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 t= he 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 unc= onfirmed tx might have a conflicting transaction get confirmed, but a lot o= f onchain wallets support this for non-RBF unconfirmed inputs because 99.9%= of the time this never happens.
* When you spend from a (con= firmed or unconfirmed) input, delete it from your db forever (because you d= o not have to worry about alternate transactions spending the same input).<= br>
* This simplifies db design, you do not have to keep track o= f states like "has been spent but tx is not confirmed yet", "has two differ= ent alternate transactions spending it that have not confirmed", "is on a t= ransaction that is not confirmed and therefore this input might disappear c= ompletely" etc.

In particular, if we want a "t= rue" full-RBF wallet:

* Suppose the user wants= to spend some amount to address A.
* The user imposes a lim= it on up to how much to spend on fees to have this spend happen.
<= div>* The wallet optimistically creates a low-fee send transaction.
* After some time, the wallet bumps up the fee by creating a new tra= nsaction.
* The wallet keeps bumping up, up to the designate= d limit, the longer the transaction is not confirmed.

Of note is that there is a *race condition* in the above case.
<= /div>
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 transactio= n 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 impos= es 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 ad= dress B.

Again, a race condition can occur ---= while the wallet is feebumping a new transaction that includes the new out= put, a random miner can find a new block that includes the old transaction.=

Thus, the wallet really needs to keep track o= f any "pending spends" and correlate them with actual transactions.

Further, of course it is convenient to be able to spe= nd 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 spe= nder keeps fee-bumping it over time.

I confess= I have not been thinking of this as well as I should have.
<= br>
Regards,
ZmnSCPxj
------=_Part_301462_445357612.1620266279269--