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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 744881197
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 13 Feb 2018 18:40:46 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149084.authsmtp.net (outmail149084.authsmtp.net
[62.13.149.84])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1AE5A1C0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 13 Feb 2018 18:40:44 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt21.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w1DIegeM010250;
Tue, 13 Feb 2018 18:40:42 GMT (envelope-from pete@petertodd.org)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id w1DIedjc049923
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Tue, 13 Feb 2018 18:40:40 GMT (envelope-from pete@petertodd.org)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 58FA5400E9;
Tue, 13 Feb 2018 18:40:37 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id 97A6020630; Tue, 13 Feb 2018 13:40:34 -0500 (EST)
Date: Tue, 13 Feb 2018 13:40:34 -0500
From: Peter Todd <pete@petertodd.org>
To: rhavar@protonmail.com
Message-ID: <20180213184034.GA10642@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
<20180212225828.GB8551@fedora-23-dvm>
<0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5"
Content-Disposition: inline
In-Reply-To: <0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 64777dd6-10ed-11e8-8106-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwEUHlAWAgsB Am4bWlxeVF17XWI7 bghPaBtcak9QXgdq
T0pMXVMcUwQceElV XE0eVhB7dQYIeXt5 ZkUsWHRcW0MuIUBg
Q04BQXAHZDJodWge UEZFdwNVdQJNeEwU a1l3GhFYa3VsNCMk
FAgyOXU9MCtqYB5Y XAAWLE4TR0lDNB8E D0lYQH0VN2NNXyI3 Lhc3bDbA
X-Authentic-SMTP: 61633532353630.1038:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
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: Tue, 13 Feb 2018 18:40:46 -0000
--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 12, 2018 at 06:23:12PM -0500, rhavar@protonmail.com wrote:
>=20
> On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>=20
> > I don't actually see where the problem is here. First of all, suppose w=
e have a
> > transaction T_a that already pays Alice with a feerate sufficiently hig=
h 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 Al=
ice,
> > T_{ab}. BIP125 only requires that double-spend to have an absolute fee =
higher
> > than the minimum relay feerate * size of the transaction.
>=20
> It's a bit of a made up term, but when Russel said "pinned" it refers to =
a child transaction that was made (i.e. in this case by Alice) and for us =
to replace our transaction we need to "unpin" it.
Yeah, sorry, I just misread what scenario you guys were talking about. IIRC=
the
term "pinned" may have even been invented by myself, as IIRC I noticed the
issue when the RBF patch was being developed years ago. I don't think I had=
a
solution at the time so I just punted on it.
> However to unpin it, the current bip125 rules require you pay not only th=
e relay of the transactions you're throwing away, but the absolute fee. Thi=
s is general is cost prohibitive, as even a normalish transaction can be sp=
ending $20 in fees.=20
>=20
> Also FWIW this whole idea of T_a and T_ab is good, but it's also pretty =
impractical at the moment due to the sheer amount complexity it introduces =
(i.e. monitoring, seeing which confirms, trying to rebroadcast the missing =
one in a way that is safe against reorgs, blah blah).
I'm not sure that's actually true, as you're only creating transactions sets
that are reorg safe. Though I don't have a detailed design in mind so I may=
be
missing something.
> > A better way to solve this class of problems may be diffed tx replaceme=
nt
> > propagation: basically broadcast a diff between the original tx and the
> > proposed replacement, allowing you to do the minimum bandwidth accounti=
ng based
> > on the size of the diff instead.
>=20
> This would definitely work for some specific use-case. For instance curre=
ntly if you do n replacements of a transaction, each time adding an additio=
nal output .. you need to pay something like O(n^2) relay fee. If you used =
a diff instead, you could probably get it to O(n)ish.=20
>=20
> But relay fee (and n) at the moment, mean it's not a big deal at all. The=
big flaw (imo) in bip125 is that you need to pay the absolute fee from the=
transactions you are evicting. And that can be from transactions you didn'=
t even generate yourself. We can already compactly represent the diff (th=
e new transaction invalidates it) the debate is more "Should you have to p=
ay the absolute fee or just relay fee for the stuff you invalidate"
Yes, the diff approach doesn't help for the pinned case.
Unfortunately the only solution I have is basically the same as what you
proposed(1) months ago: limit spends of unconfirmed outputs in some way.
So here's a question: how many wallets have actually implemented CPFP fee b=
umps
for incoming transactions?
1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688=
=2Ehtml
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAlqDMR4ACgkQJIFAPaXw
kfvIMAf/bClOIr72vWZX5CUGhzVxB/jvKKHe0FYR2M4M5v3uq+AOBpCXYqEddOMj
CXon9oC5vPVlLPdmjKhKetYeyJAMexY1cOtDsXfykdGzMX8N9PjrnMPwTjsJozBG
1AufzYmoNRfwRVwP1FH4l/dNwqtBJ3bQDCOAePxNcvHGtPkNgZYsIjaj/uYMsLbo
+1KbLICfRU3VNaB6va5YhLXOSRe+x9tJPod8O+lTkacLBGRob5RzKLxvyA1aXcuG
1bPlFLYN84J+9IbByYdxGFgMHNllSJI5jXOzrgrO6ycFpxcdawttDhtniMV65ge0
PROY/3yYqE30chbAsgqqRxBH/CAkxw==
=OOUR
-----END PGP SIGNATURE-----
--FL5UXtIhxfXey3p5--
|
