1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
Return-Path: <prayank@tutanota.de>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 79912C000D
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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"
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 <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: 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
<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>> 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--
|
