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
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
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 0B854EDA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 23:47:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com
[209.85.223.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F8B9165
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 23:47:04 +0000 (UTC)
Received: by mail-io0-f177.google.com with SMTP id e7so5059676ioj.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 15:47:04 -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=YTTStvbELdDl1iQ8g3WQRskHA5AOK848ZrEBIHEOVL8=;
b=mpA1RkiYTIcuXudVYMI+3GSQoBrqXbEqFw6PCn9yeGDxccA9dKY2TVUKq0oao9xTkb
0aVNpspyZHLRIiQz/f3Ip2/mnd2VVtwhql64azC+iUh9D1T+eki2THZXGISpRu/xqgRD
QN7c9ry/bPX/m2sjxRxq5TwRLGLuYHG32lnck=
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=YTTStvbELdDl1iQ8g3WQRskHA5AOK848ZrEBIHEOVL8=;
b=SqDuGBoLqM9q3XZj7J5YEhajce76+7JO2Hg6cddLb0tRAExjEs6ex1HJq1RB4nx2b6
9GYOMr471rjdwz9ibRrzPS8TWGfpCVQM0Gk40z3Mhz8LoaHKHefCf8S72aSZkfufjjNE
141OC5cZD/LdyCgIQU0Jx/372yYNOWgGVGMcLSZxEZDMeRWaIk/a/m76HMDM3LrIWcDm
jvFUONkQu7Ftmr+0ri4ShGenO82eU5LaIcmY3xs9nw2qmYMla/mKy7C6xc4tv/naqymn
WhIL2LW3WyetCMzwC348rD2dUW+4cHEyvZ2dS3Q9gUe1zcDOC/pDsT74tGotsufnHTOD
xuoA==
X-Gm-Message-State: APf1xPCFQ/+j5K84JTdqpvGg5tT7WdFyp0H004s+L7ISPJHCOj2OEDvj
Kj+rB8AHZdwzfdFjipiwTwEpNIBB9nZ1Q5vxSufZ6ZS7zpc=
X-Google-Smtp-Source: AH8x224u06BWk7ZouHuJsE/wBH1naQU8U+57FAKELD+YcCs0wmMHPfJEzrjz/ZtfBX0MQHH+1RHStRYH1PMxHP7/9QA=
X-Received: by 10.107.162.85 with SMTP id l82mr14884887ioe.198.1518479223732;
Mon, 12 Feb 2018 15:47:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.120.33 with HTTP; Mon, 12 Feb 2018 15:46:43 -0800 (PST)
In-Reply-To: <20180212234225.GA9131@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
<20180212225828.GB8551@fedora-23-dvm>
<CAMZUoKnFBVFhaq61wKu_CcZgRKc5aoeTa-wq9h2CXH0WWHd3NQ@mail.gmail.com>
<20180212234225.GA9131@fedora-23-dvm>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Mon, 12 Feb 2018 18:46:43 -0500
Message-ID: <CAMZUoK=BSOpUsJ=3n1jgHEAEq2M-4rigGML3Z7WN0eTgXsPp7g@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="001a11403080baced305650c7e7c"
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:47:05 -0000
--001a11403080baced305650c7e7c
Content-Type: text/plain; charset="UTF-8"
On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd <pete@petertodd.org> wrote:
> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote:
> > 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.
>
> Ah ok, I misunderstood and didn't realise you were talking about the case
> where
> Alice re-spends her unconfirmed payment. Unfortunately I don't think that
> case
> is possible to solve without putting some kind of restriction on spending
> unconfirmed outputs; with a restriction it's fairly simple to solve.
>
Adding such a restriction was Rhavar's original suggestion in
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html,
but it seems the proposal wasn't well received because it kinda destroys
CPFP.
--001a11403080baced305650c7e7c
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 6:42 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:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span=
class=3D"gmail-">On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'C=
onnor wrote:<br>
> On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd <<a href=3D"mailto:pete=
@petertodd.org">pete@petertodd.org</a>> wrote:<br>
><br>
> ><br>
> > I don't actually see where the problem is here. First of all,=
suppose we<br>
> > have a<br>
> > transaction T_a that already pays Alice with a feerate sufficient=
ly high<br>
> > that<br>
> > we expect it to get mined in the near future. If we want to pay B=
ob, we<br>
> > 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 absolut=
e fee<br>
> > higher<br>
> > than the minimum relay feerate * size of the transaction.<br>
> ><br>
><br>
> The problem is that rule 3 of BIP 125 requires you pay a fee that is h=
igher<br>
> than the the fee of T_a *plus* the fee of the sweep-transaction that t=
he<br>
> Alice has added as a unconfirmed child transaction to T_a because<br>
> double-spending to pay Alice and Bob invalidates Alice's<br>
> sweep-transaction.=C2=A0 Alice's sweep-transaction is very large, =
and hence pays<br>
> a large absolute fee even though her fee-rate is very low.=C2=A0 We do=
not have<br>
> any control over its value, hence Alice has "pinned" our RBF=
transaction.<br>
<br>
</span>Ah ok, I misunderstood and didn't realise you were talking about=
the case where<br>
Alice re-spends her unconfirmed payment. Unfortunately I don't think th=
at case<br>
is possible to solve without putting some kind of restriction on spending<b=
r>
unconfirmed outputs; with a restriction it's fairly simple to solve.<br=
>
<span class=3D"gmail-"></span></blockquote><div><br></div><div>Adding such =
a restriction was Rhavar's original suggestion in <a href=3D"https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html">https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html</a>=
, but it seems the proposal wasn't well received because it kinda destr=
oys CPFP.<br></div></div><br></div></div>
--001a11403080baced305650c7e7c--
|
