Date: Fri, 1 Oct 2021 16:53:59 +0200 (CEST)
From: Prayank <prayank@tutanota.de>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <MkwLF4W--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_815643_1315444824.1633100039490"
Subject: [bitcoin-dev] Replacement transaction and ancestor score bug
Precedence: list

------=_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

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>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.<br></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">PR: <a href=3D"https://github.=
com/bitcoin/bitcoin/pull/23121">https://github.com/bitcoin/bitcoin/pull/231=
21</a><br></div><div dir=3D"auto"><br></div><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:<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div>&gt; 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).<br></div><div><br></div><div><br></div></div><div>-- <br></div><di=
v>Prayank<br></div><div><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br>=
</div>  </body>
</html>

------=_Part_815643_1315444824.1633100039490--