From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8E479C0001 for ; Mon, 3 May 2021 04:02:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 673B540F9C for ; Mon, 3 May 2021 04:02:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=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 (1024-bit key) header.d=protonmail.com 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 A6JrO6gSnkgy for ; Mon, 3 May 2021 04:02:17 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by smtp4.osuosl.org (Postfix) with ESMTPS id 80A1140F9B for ; Mon, 3 May 2021 04:02:17 +0000 (UTC) Date: Mon, 03 May 2021 04:02:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1620014533; bh=QYMf+TS5T5NfpEFaZEZALER3QTf7IVrys7RVpsjxOY8=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=Op1NI6Z7Oqwl0bQtwQxMXImCNCPfbKqDzJJkyWS2LHLeP33UkG/ea7EinYdv4j3b7 yxMxBL2RnC2SY9AYPpU2wVhFuFKJkFES3+kbBKIR0DR1ErkZ+A6rCTBXpvAllZnPn/ gvceImYTKPXhV5Ni9mEhlxHU4wp8/sQsNmPGAlLo= To: Prayank , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 03 May 2021 04:02:19 -0000 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