From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 79912C000D for ; Fri, 1 Oct 2021 14:54:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5BF3C614EA for ; Fri, 1 Oct 2021 14:54:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.de Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbR-2MTdUDT4 for ; Fri, 1 Oct 2021 14:54: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 smtp3.osuosl.org (Postfix) with ESMTPS id 31F31614B5 for ; Fri, 1 Oct 2021 14:54:02 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 7BD68FA0D1F for ; Fri, 1 Oct 2021 14:53:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1633100039; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=pgsDoIljL3Bw6pAIsqSV22i7BbpRBsPFmlbuWfduxN4=; b=Vic9AKxkJyWpFHssq4xtvQvZpu3yDUA05oskuZ5n/lb6sxOEtyfHbTTaDx/ZCEFX 3iZtEx0MJZF9dUm6Dk6jgiEqvN5si4EzPtzDcjoGBKLBvrTADMB9b/MgwjwP+t1/Kgs uD3Amw6+4K60sRRSjCeUuWGBMxOLUEsmpAFPb/MTB6sTRcfPJrE7Au8NHlBcs/yT93O t4H8XpOhBCHCGCEg+LFck0mRxrEH8VikesgAQWzFuNE3s2BogpUO7bSqP1gx7y4Xt0P 7SZrNLp5wyUdACv2vQ1+bI2mp0uXi3G94BKEsq98+mKEwDB2fJAGtAzagQeVsLvH/I0 8saw0s2+/g== Date: Fri, 1 Oct 2021 16:53:59 +0200 (CEST) From: Prayank To: Bitcoin Dev Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_815643_1315444824.1633100039490" X-Mailman-Approved-At: Fri, 01 Oct 2021 15:38:25 +0000 Subject: [bitcoin-dev] Replacement transaction and ancestor score bug 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: Fri, 01 Oct 2021 14:54:03 -0000 ------=_Part_815643_1315444824.1633100039490 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This pull request was mentioned in the thread: "Proposal: Package Mempool Accept and Package RBF" however I am not sure if everyone would have read all the emails if they were not interested in packages. Also not possible to keep track of each pull request in Bitcoin Core repository. PR: https://github.com/bitcoin/bitcoin/pull/23121 I came across this pull request while reviewing few others and found the details in comments interesting. I think everyone who is using Bitcoin and RBF should be aware of this bug. I won't add my opinions or comments, copying few lines from PR: > However, Example N shows how this strategy can cause us to accept an replacement transaction that is actually less economical to mine than the original. Assume all transactions have a vsize of 100vB. A user wants to replace A, which has an ancestor score of 10sat/vB, with transaction C. Suppose they want to spend an unconfirmed output from transaction B, which has an ancestor score of 1sat/vB (maybe their wallet doesn't have enough funds to provide a higher fee using only confirmed inputs). BIP125#2 prevents scenario N1, where the inclusion of another unconfirmed input means C has an ancestor score of 8sat/vB and thus less economical to mine than A. However, it does not prevent scenario M2, where the user splits off a 1-input 1-output transaction, C*, in order to be able to include the output from B. This causes us to incorrectly accept C (7.5sat/vB including its parent B) in favor of A (10sat/vB). -- Prayank A3B1 E430 2298 178F ------=_Part_815643_1315444824.1633100039490 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This pull request was mentioned in the thread: "Proposal: Package Memp= ool Accept and Package RBF" however I am not sure if everyone would have re= ad all the emails if they were not interested in packages. Also not possibl= e to keep track of each pull request in Bitcoin Core repository.
<= div dir=3D"auto">

I came across= this pull request while reviewing few others and found the details in comm= ents interesting. I think everyone who is using Bitcoin and RBF should be a= ware of this bug. I won't add my opinions or comments, copying few lines fr= om PR:

> How= ever, Example N shows how this strategy can cause us to accept an replaceme= nt transaction that is actually less economical to mine than the original. = Assume all transactions have a vsize of 100vB. A user wants to replace A, w= hich has an ancestor score of 10sat/vB, with transaction C. Suppose they wa= nt to spend an unconfirmed output from transaction B, which has an ancestor= score of 1sat/vB (maybe their wallet doesn't have enough funds to provide = a higher fee using only confirmed inputs). BIP125#2 prevents scenario N1, w= here the inclusion of another unconfirmed input means C has an ancestor sco= re of 8sat/vB and thus less economical to mine than A. However, it does not= prevent scenario M2, where the user splits off a 1-input 1-output transact= ion, C*, in order to be able to include the output from B. This causes us t= o incorrectly accept C (7.5sat/vB including its parent B) in favor of A (10= sat/vB).


--
Prayank

A3B1 E430 2298 178F
=
------=_Part_815643_1315444824.1633100039490--