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
126
127
128
129
130
131
|
Return-Path: <murch@murch.one>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 15F01C0037
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jan 2024 17:27:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id EC9098258A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jan 2024 17:27:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org EC9098258A
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1
X-Spam-Level: *
X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_50=0.8,
DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001,
SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id UybVGzUF1Sd8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jan 2024 17:27:11 +0000 (UTC)
Received: from farbauti.uberspace.de (farbauti.uberspace.de [185.26.156.235])
by smtp1.osuosl.org (Postfix) with ESMTPS id DDBDC8257D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jan 2024 17:27:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DDBDC8257D
Received: (qmail 10034 invoked by uid 989); 28 Jan 2024 17:27:08 -0000
Authentication-Results: farbauti.uberspace.de;
auth=pass (plain)
Received: from unknown (HELO unkown) (::1)
by farbauti.uberspace.de (Haraka/3.0.1) with ESMTPSA;
Sun, 28 Jan 2024 18:27:07 +0100
Message-ID: <42006209-4ea4-4008-b3b3-556a8461323c@murch.one>
Date: Sun, 28 Jan 2024 12:27:06 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <Zalsq+Nq7RRr/CAR@petertodd.org>
<9a89eca8-61fd-4156-825d-c9b718dc3034@murch.one>
<ZbSueoReTvEmm1s9@petertodd.org>
Content-Language: en-US
From: Murch <murch@murch.one>
In-Reply-To: <ZbSueoReTvEmm1s9@petertodd.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Bar: -
X-Rspamd-Report: BAYES_HAM(-0.981172) XM_UA_NO_VERSION(0.01) MIME_GOOD(-0.1)
X-Rspamd-Score: -1.071172
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=murch.one; s=uberspace;
h=from; bh=ZXbuZ9QPSkWZOytzbd0u9JbRb/dVOGEyw/Nw/2oCByg=;
b=ewJC48/RJsTQMs7aIz9kpJmNao3ldFn/olHflyQ0RKt7wImcm0tVCkfJ9Vh8Ox89wjqJkdof8R
+6QAHR3y6ayZYkP+kguv7qgb2e9uOj3spcenwXgWV3QP0B3fIM57d7E7uAR176FowFlk2YagTru3
Jkoh4DfVF+gnsBiEimQK9wSOntcchn/I4N+GLrn/MoUX/BNOgCGbjHLI1gMZTgsP/7/Ze62tFdBF
JM/0HTMPzblzAynMOxUnshJky8rI4G6YVVGJReO3lB2o6MJaGaLlurayqIeQ+K76g77DRUB0/1s7
YYt2O55zqGIicCNfcFLLx4b14k3L+ir/IV7rxGsuKDWXNJtT3AxAE4jFU3sSWe46/53/wpRhiv8m
dh0fIPKHzxxdkyOz4+H7dPhiygX3N6vSwFpsoXSLxyvGp4o9+OBKKraLwBmD3rbx19+cF6Y/U2lJ
hrl8GBM8aghK22cZeqxVu0x619xVcaHFYExaorgX5RhhpJb+KfAzOmpCDNutniA7bRRH2aka9OL5
O4xCBrMFveVevu4iOLEM3xxA9Axcn5z7zTAaW1TA6bBUBAIRJIr6+IGJNIYhGLZ6TpMBZBkYc3p6
A/0j9FhOBelVEq8xtBsX5OPIxWHyXWbZyDr2/+eaw4EhMYVA8765N+XBHSXhYhWYEbmQLKk6aKY8
Y=
Subject: Re: [bitcoin-dev] One-Shot Replace-By-Fee-Rate
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: Sun, 28 Jan 2024 17:27:13 -0000
Hi Peter,
Thanks you for investigate my concern and replicate the scenario I drafted.
On 27.01.24 02:19, Peter Todd wrote:
> I actually tried this attack out, and it fails at step #4 due to the Rule #6,
> PaysMoreThanConflicts, check.
>
> While on stacker.news you stated that:
>
> tx_HS has 5000 vB and pays 21 s/vB, but since it spends an output from a
> low-feerate parent, it’s mining score is only 1.95 s/vB.
>
> and
>
> You RBF tx_LL and tx_HS with tx_LM that has 100,000 vB and pays 3.05 s/vB (fee:
> 305,000 s) by spending the outputs C1 and C2. This is permitted, since only
> tx_LL is a direct conflict, so the feerate of tx_HS does not have to be beat
> directly.
>
> tx_HS _is_ considered to be a direct conflict, and its raw fee-rate _does_ have
> to be beat directly. While ts_HS does spend an unconfirmed output, it appears
> that the fee-rate PaysMoreThanConflicts uses to calculate if ts_HS can be
> beaten is ts_HS's raw fee-rate. So looks like your understanding was incorrect
> on these two points.
I agree in the detail, but not about the big picture. You are right that
it’s a problem that `tx_LM` and `tx_HS` spend the same input and
therefore are direct conflicts.
Luckily, it is unnecessary for my scenario that `tx_LM` and `tx_HS`
conflict. The scenario only requires that `tx_LM` conflicts with `tx_LL`
and `tx_RBFr`. `tx_HS` is supposed to get dropped indirectly per the
conflict with `tx_LL`.
It seems to me that my example attack should work when a third confirmed
input `c3` is introduced as follows:
`tx_LM` spends `c3` instead of `c2`, and `tx_RBFr` spends both `c2` and
`c3`, which allows the following four conflicts:
- `tx_HS` and `tx_RBFr` conflict on spending `c2`
- `tx_HS` and `tx_LS` conflict on spending `tx_LL:0`
- `tx_LL` and `tx_LM` conflict on spending `c1`
- `tx_LM` and `tx_RBFr` conflict on spending `c3`
`tx_RBFr` would end up slightly bigger and therefore have a bigger fee,
but otherwise the number should work out fine as they are.
I have not verified this yet (thanks for sharing your code), but I might
be able to take another look in the coming week if you haven’t by then.
It seems to me that my main point stands, though: the proposed RBFr
rules would enable infinite replacement cycles in combination with the
existing RBF rules.
Murch
|
