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
|
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 52903ECB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 23:42:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149080.authsmtp.com (outmail149080.authsmtp.com
[62.13.149.80])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 85A89165
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Feb 2018 23:42:31 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt24.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w1CNgTfj062215;
Mon, 12 Feb 2018 23:42:29 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 w1CNgRQS075573
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Mon, 12 Feb 2018 23:42:28 GMT (envelope-from pete@petertodd.org)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 1E59940110;
Mon, 12 Feb 2018 23:42:27 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id 3290F20630; Mon, 12 Feb 2018 18:42:25 -0500 (EST)
Date: Mon, 12 Feb 2018 18:42:25 -0500
From: Peter Todd <pete@petertodd.org>
To: "Russell O'Connor" <roconnor@blockstream.io>
Message-ID: <20180212234225.GA9131@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
<20180212225828.GB8551@fedora-23-dvm>
<CAMZUoKnFBVFhaq61wKu_CcZgRKc5aoeTa-wq9h2CXH0WWHd3NQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv"
Content-Disposition: inline
In-Reply-To: <CAMZUoKnFBVFhaq61wKu_CcZgRKc5aoeTa-wq9h2CXH0WWHd3NQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 62f2464f-104e-11e8-8106-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwAUHlAWAgsB Am4bWVdeVF97W2s7 bghPaBtcak9QXgdq
T0pMXVMcUwQbf0tj Z30eVRx3cAYIcH53 ZwhkXCZZWEJ+I1t8
QkoBCGwHMG99YGEf Vl1YdwJRcQRMLU5E Y1gxNiYHcQ5VPz4z
GA41ejw8IwAXEilL QxoMMVMUTg4hPwZ0 HkpfVQ8FMwUdQCEy JA1gQiN4
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: Mon, 12 Feb 2018 23:42:32 -0000
--ZGiS0Q5IWpPtfppv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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:
>=20
> >
> > 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 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
> The problem is that rule 3 of BIP 125 requires you pay a fee that is high=
er
> 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 pa=
ys
> 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 w=
here
Alice re-spends her unconfirmed payment. Unfortunately I don't think that c=
ase
is possible to solve without putting some kind of restriction on spending
unconfirmed outputs; with a restriction it's fairly simple to solve.
> > I think what you mean here should be the effective fee rate of the maxi=
mum
> > feerate package that can be built from the set of transactions that beg=
ins
> > 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 f=
irst
> > implemented.
> >
>=20
> Yes, that is what I mean. My proposal was off-the-mark.
>=20
> Surely CPFP is already computing the package-fee rates of mempool
> transactions. That is the value we need to compute.
True, maybe we can just reuse the CPFP calculation now. That said, AFAIK th=
at's
only done in the miner code, not the mempool, so that may not be trivial to
actually do.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--ZGiS0Q5IWpPtfppv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAlqCJl0ACgkQJIFAPaXw
kfsZjggAjXkZVdlnC9GSKOyTixz0f4qROGpCZ7IMF3O+Nb0x+LSlj0vZAnu+k5oZ
7cTkzed3MXVdmfKPw463PMPh2uhp8D1oLatgLk+PkRtsTkoNphDARoJAFpJXHKSV
gRYRKLjhLZXZt4Hu+ZLJI8Gifm9tjevaNw3yUKFGaZC1BWF8gFxYaSYtWT/IalsU
rlElk+VASwwKg0bXTxVp9K4dbY+3l/skfzcTpQ4u+bniPwQmkSzr2KHlMTkWj6jk
1v5myMdcQ2/dP485551kjGwoURqiXDUo1DEH59Bf+pRU553QTYrysjInxQqYG0TT
D4/ZdrjPoG9JWRXoiSBaXoVy3wtU6Q==
=/I+S
-----END PGP SIGNATURE-----
--ZGiS0Q5IWpPtfppv--
|
