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
|
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 41BF210E8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Mar 2018 18:28:12 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148099.authsmtp.net (outmail148099.authsmtp.net
[62.13.148.99])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 556845E1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Mar 2018 18:28:11 +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 w29IS8jQ041874;
Fri, 9 Mar 2018 18:28:08 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 w29IS6et083863
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Fri, 9 Mar 2018 18:28:07 GMT (envelope-from pete@petertodd.org)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 4DFB540090;
Fri, 9 Mar 2018 18:28:06 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id C04C620065; Fri, 9 Mar 2018 13:28:03 -0500 (EST)
Date: Fri, 9 Mar 2018 13:28:03 -0500
From: Peter Todd <pete@petertodd.org>
To: "Russell O'Connor" <roconnor@blockstream.io>
Message-ID: <20180309182803.GE2786@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>
<CAMZUoK=Htds5fu5vnqAhEoZDrwHALKe6uwqXnmJb17pa_peFFw@mail.gmail.com>
<20180301151129.GA9373@fedora-23-dvm>
<CAMZUoKkG8tbdb+6tGmpvgXb-=3Tu4JsTWXz77o3EC+4Bcbd17A@mail.gmail.com>
<20180308183426.GA1093@fedora-23-dvm>
<CAMZUoKkDnJv33H-DveHtwpnyALS5LoX-OAnabJyvPo4c1DBJRQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="6e7ZaeXHKrTJCxdu"
Content-Disposition: inline
In-Reply-To: <CAMZUoKkDnJv33H-DveHtwpnyALS5LoX-OAnabJyvPo4c1DBJRQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 9d84768a-23c7-11e8-8106-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgsUFVQGAgsB Am4bWlxeUlV7WWs7 bghPaBtcak9QXgdq
T0pMXVMcUwdheH8H U1oeWhp6cQYIeX5y Z0IsVyRTWEN8fRdg
QE0HEnAHZDJodWge UEZFdwNVdQJNeEwU a1l3GhFYa3VsNCMk
FAgyOXU9MCtqYB5Y XAAWLE4TR0lDNB8E D0lYQH0VN2NNXyI3 Lhc3bDYv
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: Fri, 09 Mar 2018 18:28:12 -0000
--6e7ZaeXHKrTJCxdu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Mar 08, 2018 at 03:07:43PM -0500, Russell O'Connor wrote:
> On Thu, Mar 8, 2018 at 1:34 PM, Peter Todd <pete@petertodd.org> wrote:
> > But that's not a good argument: whether or not normal users are trying =
to
> > attack each other has nothing to do with whether or not you're opening =
up
> > an
> > attack by relaxing anti-DoS protections.
> >
>=20
> I'm not suggesting removing the anti-DoS protections. I'm suggesting that
> replaced transaction require a fee increase of at least the min-fee-rate
> times the size of all the transactions being ejected (in addition to the
> other proposed requirements).
Fair: you're not removing them entirely, but you are weakening them compare=
d to
the status quo.
> > Equally, how often are normal users who aren't attacking each other
> > creating
> > issues anyway? You can always have your wallet code just skip use of RBF
> >
> replacements in the event that someone does spend an unconfirmed output t=
hat
> > you sent them; how often does this actually happen in practice?
>=20
>=20
> Just ask rhavar. It happens regularly.
>=20
> Not many wallets let you spend unconfirmed outputs that you didn't create.
> >
>=20
> The problem is with institutional wallets sweeping incoming payments. It
> seems that in practice they are happy to sweep unconfirmed outputs.
Pity, that does sound like a problem. :(
> Setting all of the above aside for a moment. We need to understand that
> rational miners are going to prefer to transactions with higher package f=
ee
> rates regardless of whatever your personal preferred RBF policy is. If we
> do not bring the RBF policy to alignment with what is economically
> rational, then miners are going to change their own policies anyways,
> probably all in slightly different ways. It behooves everyone to develop=
a
> reasonable standard RBF policy, that is still robust against possible DoS
> vectors, and aligns with miner incentives, so that all participants know
> what behaviour they can reasonably expect. It is simply a bonus that this
> change in RBF policy also partially mitigates the problem of pinned
> transactions.
Miners and full nodes have slightly different priorities here; it's not cle=
ar
to me why it matters that they implement slightly different policies.
Still, re-reading your initital post, I'm convinced that the weakening of t=
he
DoS protections is probably not a huge problem, so maybe lets try this in a
release and see what happens.
Notably, if people actually use this new replacement behavior, the institut=
ions
doing these sweeps of unconfirmed outputs might stop doing that! That's
probably a good thing, as respends of potentially conflicted unconfirmed
outputs can be dangerous in reorgs; we're better off if outputs are buried
deeply before being spent again.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--6e7ZaeXHKrTJCxdu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGSBAEBCAB8FiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAlqi0jBeFIAAAAAAFQBA
YmxvY2toYXNoQGJpdGNvaW4ub3JnMDAwMDAwMDAwMDAwMDAwMDAwMzFmOTYxY2Ri
YjQ3MjliNjcxMGVmOTg5MWY4M2QxMDljODA0ODg5NTllMDFjYwAKCRAkgUA9pfCR
+4brB/kBjoZmGhMZ1Gj7NcvHRRhxYVMyO0Uze8DzzRqj+Nn/e3HI/Zdy0p6/bndq
oByRKyUWywrlYi3RcfRdfkt0zDbrF62yfr6MTS4C1v4/8nCNG87lP3nuL/wJvYSX
pBH/3ecWQfx8Vi8IoHXKwTOuONfmp22NSL3NzNhrT+3hqFQqQfZvmcNUcKV9US4H
YfCjyyiWro8vMtv4jTWfeGhgp7Gl3h6R/MHdbQAgMBL6zGf9M81J9W43B2qrJsvp
wwWeHdjM9tO4D//ed2H4axKyIGU+sqqiIK02mw5hRo7D91eQJiZQiy+3C3IMvlw4
5TGR8mP6c7ir4MynrON4ak9RJoyl
=A9/W
-----END PGP SIGNATURE-----
--6e7ZaeXHKrTJCxdu--
|
