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
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F2CF11074
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 23:20:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f172.google.com (mail-io0-f172.google.com
[209.85.223.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 57866D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 23:20:01 +0000 (UTC)
Received: by mail-io0-f172.google.com with SMTP id m11so19218186iob.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 15:20:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=RvxpL0g9jKfy4K9LUicE9K/GzW/E/R0ZTwLDiLUlWUU=;
b=iPf4I4iJB7UuQRp5iu0JowqyjdS2ZFcfLf1Q4c/S6hw1X8lohdqFz5domSC85mIBmm
d1yoQijgH3u8OWTfi1unSE2ZoQwdmB5paOxQnsIJF7u4veq7XNVIe03UwaMFGJTwuRTi
G35OJHstb4CL79jYecnOjRkeWRfBJl/Kaj1Q0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=RvxpL0g9jKfy4K9LUicE9K/GzW/E/R0ZTwLDiLUlWUU=;
b=IoPbzFFBwEPu/CnL0Q+RGzg1diP4DB4Uo2zpu/zzZ5466w2vz52CuzaCAhAReJk1p9
cC0k6mssb0VLjGNL2pZDkATMKBMFsvpQxJJOUUABpL/AW+mr2eZSPycDu6Q1WMd3rU7A
JyumPlzk4QJgZgRX4dCxBVmVcyUB9+sHDns5AkdNSCDvtetRtHKkE+PY9W25tNycasav
VeP5DKnIh5GXZq4NW/3budJEo8CcANfMVswG0X7G1JyXWFK3XqkulChXswNsD1t8XNbz
pEXdJcpUzs90TP4HhnCtBrckYzI29Ob8WLPdTCWY+eKGX41Xb1RMwvXiVcYPYG+gUwRa
kbPA==
X-Gm-Message-State: APf1xPBqaOnsEDNpJ0cjWz7ebyfTN7Ofs7+HyMgf7rUfo/ElqPWkFEhq
cmxxZwAkpnzWgQi5wcB1ld5t3Qu1S5zP+fs3wrU+OUYt
X-Google-Smtp-Source: AH8x225/kJVs94PogU/XyWcTmXrA9iiSk1ytDN0FahdlAh5/GDTC7h1QxUk+NdCvFFJhZcUneGP1vmKghRa/BvbwglY=
X-Received: by 10.107.162.85 with SMTP id l82mr14814484ioe.198.1518477600596;
Mon, 12 Feb 2018 15:20:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.120.33 with HTTP; Mon, 12 Feb 2018 15:19:40 -0800 (PST)
In-Reply-To: <20180212225828.GB8551@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
<20180212225828.GB8551@fedora-23-dvm>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Mon, 12 Feb 2018 18:19:40 -0500
Message-ID: <CAMZUoKnFBVFhaq61wKu_CcZgRKc5aoeTa-wq9h2CXH0WWHd3NQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="001a11403080fbc79005650c1da4"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Mon, 12 Feb 2018 23:20:02 -0000
--001a11403080fbc79005650c1da4
Content-Type: text/plain; charset="UTF-8"
On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd <pete@petertodd.org> wrote:
>
> I don't actually see where the problem is here. First of all, suppose we
> have a
> transaction T_a that already pays Alice with a feerate sufficiently high
> that
> we expect it to get mined in the near future. If we want to pay Bob, we
> can do
> that by simply creating a double-spend of T_a that pays both Bob and Alice,
> T_{ab}. BIP125 only requires that double-spend to have an absolute fee
> higher
> than the minimum relay feerate * size of the transaction.
>
The problem is that rule 3 of BIP 125 requires you pay a fee that is higher
than the the fee of T_a *plus* the fee of the sweep-transaction that the
Alice has added as a unconfirmed child transaction to T_a because
double-spending to pay Alice and Bob invalidates Alice's
sweep-transaction. Alice's sweep-transaction is very large, and hence pays
a large absolute fee even though her fee-rate is very low. We do not have
any control over its value, hence Alice has "pinned" our RBF transaction.
> 3'. The replacement transaction pays a fee rate of at least the effective
> > fee rate of any chain of transactions from the set of original
> transactions
> > that begins with the root of the original transaction set.
>
> I think what you mean here should be the effective fee rate of the maximum
> feerate package that can be built from the set of transactions that begins
> with
> the candidate replacement. But actually calculating this is I believe
> non-trivial, which is why I didn't implement it this way when RBF was first
> implemented.
>
Yes, that is what I mean. My proposal was off-the-mark.
Surely CPFP is already computing the package-fee rates of mempool
transactions. That is the value we need to compute.
--001a11403080fbc79005650c1da4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd <span dir=3D"ltr"><<a hr=
ef=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
</span>I don't actually see where the problem is here. First of all, su=
ppose we have a<br>
transaction T_a that already pays Alice with a feerate sufficiently high th=
at<br>
we expect it to get mined in the near future. If we want to pay Bob, we can=
do<br>
that by simply creating a double-spend of T_a that pays both Bob and Alice,=
<br>
T_{ab}. BIP125 only requires that double-spend to have an absolute fee high=
er<br>
than the minimum relay feerate * size of the transaction.<br></blockquote><=
div><br></div><div>The problem is that rule 3 of BIP 125 requires you pay a=
fee that is higher than the the fee of T_a *plus* the fee of the sweep-tra=
nsaction that the Alice has added as a unconfirmed child transaction to T_a=
because double-spending to pay Alice and Bob invalidates Alice's sweep=
-transaction.=C2=A0 Alice's sweep-transaction is very large, and hence =
pays a large absolute fee even though her fee-rate is very low.=C2=A0 We do=
not have any control over its value, hence Alice has "pinned" ou=
r RBF transaction.<br></div><span class=3D""></span><span class=3D""></span=
><br><span class=3D""></span><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"=
">
> 3'. The replacement transaction pays a fee rate of at least the ef=
fective<br>
> fee rate of any chain of transactions from the set of original transac=
tions<br>
> that begins with the root of the original transaction set.<br>
<br>
</span>I think what you mean here should be the effective fee rate of the m=
aximum<br>
feerate package that can be built from the set of transactions that begins =
with<br>
the candidate replacement. But actually calculating this is I believe<br>
non-trivial, which is why I didn't implement it this way when RBF was f=
irst<br>
implemented.<span class=3D""><br></span></blockquote><div><br></div><div>Ye=
s, that is what I mean.=C2=A0 My proposal was off-the-mark.<br></div><div><=
br>Surely CPFP is already computing the package-fee rates of mempool transa=
ctions.=C2=A0 That is the value we need to compute.<br></div></div></div></=
div>
--001a11403080fbc79005650c1da4--
|
