path: root/64/b4a3695824c97b4592958051132ae786faa394

Return-Path: <prayank@tutanota.de>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D4A6DC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <prayank@tutanota.de>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <MZzOKmO--3-2@tutanota.de>
In-Reply-To: <FD5iXWFzOy1VYbksNsxzhBg-NGiiedTutilM0qpo4jqU15BAjhaZ4hQSqUTJATW8Fjk2kOzKPoGNgZVRIppZlHf1d_7wcYOu9vZIEZ1-x9U=@protonmail.com>
References: <MZZT0_o--3-2@tutanota.de>
 <FD5iXWFzOy1VYbksNsxzhBg-NGiiedTutilM0qpo4jqU15BAjhaZ4hQSqUTJATW8Fjk2kOzKPoGNgZVRIppZlHf1d_7wcYOu9vZIEZ1-x9U=@protonmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>Good morning ZmnSCPxj,<br></div><div><br></div><div>Thanks for your re=
sponse. I agree there are few exceptions:&nbsp;<br></div><div><br></div><di=
v>1.Unconfirmed output can be spent resulting in conflict with RBF<br></div=
><div>2.Race condition and mining pool may include old transaction with low=
 fee</div><div><br></div><div>I am trying few things related to RBF and han=
dling such exceptions, will share if I find anything interesting.</div><div=
><br></div><div>-- <br></div><div>Prayank</div><div><br></div><div><br></di=
v><div>May 3, 2021, 09:32 by ZmnSCPxj@protonmail.com:<br></div><blockquote =
class=3D"tutanota_quote" style=3D"border-left: 1px solid #93A3B8; padding-l=
eft: 10px; margin-left: 5px;"><div>Good morning Prayank,<br></div><div><br>=
</div><div>I believe a "true" full-RBF wallet should be what every onchain =
wallet aspires to.<br></div><div><br></div><div>However, I think a lot of t=
he effort necessary here has to do with sheer engineering issues.<br></div>=
<div><br></div><div>For example, if you think "RBF does not exist", you can=
 do things like:<br></div><div><br></div><div>* Spend an unconfirmed input =
from a third party.<br></div><div> * 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.<br></div><div>* 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></div><div> * 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.<br></div><div><br></div><div>In particular, if we want a "t=
rue" full-RBF wallet:<br></div><div><br></div><div>* Suppose the user wants=
 to spend some amount to address A.<br></div><div> * The user imposes a lim=
it on up to how much to spend on fees to have this spend happen.<br></div><=
div>* The wallet optimistically creates a low-fee send transaction.<br></di=
v><div>* After some time, the wallet bumps up the fee by creating a new tra=
nsaction.<br></div><div> * The wallet keeps bumping up, up to the designate=
d limit, the longer the transaction is not confirmed.<br></div><div><br></d=
iv><div>Of note is that there is a *race condition* in the above case.<br><=
/div><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.<br></div><div><br></div><div>Now consider the subsequent =
user story.<br></div><div><br></div><div>* After some time, the user wants =
to spend another amount to address B.<br></div><div> * Again the user impos=
es a limit on how much to spend on fees to have this spend happen.<br></div=
><div>* The wallet RBFs the existing transaction to include the spend to ad=
dress B.<br></div><div><br></div><div>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.=
<br></div><div><br></div><div>Thus, the wallet really needs to keep track o=
f any "pending spends" and correlate them with actual transactions.<br></di=
v><div><br></div><div>Further, of course it is convenient to be able to spe=
nd money even while it is unconfirmed.<br></div><div>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.<br></div><div><br></div><div>I confess=
 I have not been thinking of this as well as I should have.<br></div><div><=
br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div></blockquote>  </bod=
y>
</html>

------=_Part_301462_445357612.1620266279269--