summaryrefslogtreecommitdiff
path: root/50/4c81bd58970a6e53e17ddc54f14c2115a1bfc3
blob: 8d3d6704a5898eae2be12000123ae6a16a434696 (plain)
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
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
Return-Path: <rhavar@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 89FD6FA2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Mar 2018 18:40:40 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.18])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 651195E1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Mar 2018 18:40:39 +0000 (UTC)
Date: Fri, 09 Mar 2018 13:40:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1520620836;
	bh=i8VBm0yHTckSMh7Vk+iohSAxFvhXDDG4oXA80EaybHk=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=HQbdRVfrJZE8qKptlSUI+1sd3s9EEzU4/cQh3umkqFihvy7d3mYKSpdNrzk3VVHX5
	J0zB+6muiOqttACD8MGHlsvy23D5LfBSeC0mOsgVlXRkb2H9x6sTVuzJS4KXwwA1XM
	oVBBqqAkEncXISn6llcdCUYasqUdSaucCEXKclQo=
To: Peter Todd <pete@petertodd.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: rhavar@protonmail.com
Reply-To: rhavar@protonmail.com
Message-ID: <ZmiZUf6iUcddY1CKMADBa8FryCgrZ1235R4bHParR8NpwibjA-EY38D_GElA9jv4Z-zPZE9juQKgJjpd4MFfjg9ySFvO51dOHNoObHdaLjo=@protonmail.com>
In-Reply-To: <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>
	<20180309182803.GE2786@fedora-23-dvm>
Feedback-ID: RdfuD--Ffc-FNb_4UIG1XA3s5stj1f6Yt84KENdha_3WoiW3STYpu7X5uGR72LvTfQZpxEhSRHGSlNfV5XM5RA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	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
X-Mailman-Approved-At: Fri, 09 Mar 2018 20:03:41 +0000
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:40:40 -0000

> Still, re-reading your initital post, I'm convinced that the weakening of=
 the
> DoS protections is probably not a huge problem, so maybe lets try this in=
 a
> release and see what happens.

Awesome! I very much agree. The relaxation of some of these DoS prevention =
rules I think will really open up a lot of use cases and adoption=20

> Notably, if people actually use this new replacement behavior, the instit=
utions
> doing these sweeps of unconfirmed outputs might stop doing that!=20

Agree, I'm pretty sure it's unintentional. I know a lot of services struggl=
e with coin selection, so what they do is conceptually have a receive walle=
t from which they can sweep to their hot wallet (or cold storage) to keep t=
heir utxo manageable.

Currently some of them are sweeping unconfirmed inputs with it, but I don't=
 think it's a conscious design choice, just something that happens to be wo=
rking well now.

(FWIW I observed this behavior like 6+ months ago, I haven't kept track of =
if it's still happening or how often. But at the time I had to write off th=
e idea of low-fee rbf batch transactions as it was happening too often to b=
e feasible)


=E2=80=8B-Ryan=E2=80=8B

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90

On March 9, 2018 1:28 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.lin=
uxfoundation.org> wrote:

> =E2=80=8B=E2=80=8B
>=20
> On Thu, Mar 08, 2018 at 03:07:43PM -0500, Russell O'Connor wrote:
>=20
> > On Thu, Mar 8, 2018 at 1:34 PM, Peter Todd pete@petertodd.org wrote:
> >=20
> > > But that's not a good argument: whether or not normal users are tryin=
g to
> > >=20
> > > attack each other has nothing to do with whether or not you're openin=
g up
> > >=20
> > > an
> > >=20
> > > attack by relaxing anti-DoS protections.
> >=20
> > I'm not suggesting removing the anti-DoS protections. I'm suggesting th=
at
> >=20
> > replaced transaction require a fee increase of at least the min-fee-rat=
e
> >=20
> > times the size of all the transactions being ejected (in addition to th=
e
> >=20
> > other proposed requirements).
>=20
> Fair: you're not removing them entirely, but you are weakening them compa=
red to
>=20
> the status quo.
>=20
> > > Equally, how often are normal users who aren't attacking each other
> > >=20
> > > creating
> > >=20
> > > issues anyway? You can always have your wallet code just skip use of =
RBF
> >=20
> > replacements in the event that someone does spend an unconfirmed output=
 that
> >=20
> > > you sent them; how often does this actually happen in practice?
> >=20
> > Just ask rhavar. It happens regularly.
> >=20
> > Not many wallets let you spend unconfirmed outputs that you didn't crea=
te.
> >=20
> > >=20
> >=20
> > The problem is with institutional wallets sweeping incoming payments. I=
t
> >=20
> > seems that in practice they are happy to sweep unconfirmed outputs.
>=20
> Pity, that does sound like a problem. :(
>=20
> > Setting all of the above aside for a moment. We need to understand that
> >=20
> > rational miners are going to prefer to transactions with higher package=
 fee
> >=20
> > rates regardless of whatever your personal preferred RBF policy is. If =
we
> >=20
> > do not bring the RBF policy to alignment with what is economically
> >=20
> > rational, then miners are going to change their own policies anyways,
> >=20
> > probably all in slightly different ways. It behooves everyone to develo=
p a
> >=20
> > reasonable standard RBF policy, that is still robust against possible D=
oS
> >=20
> > vectors, and aligns with miner incentives, so that all participants kno=
w
> >=20
> > what behaviour they can reasonably expect. It is simply a bonus that th=
is
> >=20
> > change in RBF policy also partially mitigates the problem of pinned
> >=20
> > transactions.
>=20
> Miners and full nodes have slightly different priorities here; it's not c=
lear
>=20
> to me why it matters that they implement slightly different policies.
>=20
> Still, re-reading your initital post, I'm convinced that the weakening of=
 the
>=20
> DoS protections is probably not a huge problem, so maybe lets try this in=
 a
>=20
> release and see what happens.
>=20
> Notably, if people actually use this new replacement behavior, the instit=
utions
>=20
> doing these sweeps of unconfirmed outputs might stop doing that! That's
>=20
> probably a good thing, as respends of potentially conflicted unconfirmed
>=20
> outputs can be dangerous in reorgs; we're better off if outputs are burie=
d
>=20
> deeply before being spent again.
>=20
>=20
> -------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
----
>=20
> https://petertodd.org 'peter'\[:-1\]@petertodd.org
>=20
> bitcoin-dev mailing list
>=20
> bitcoin-dev@lists.linuxfoundation.org
>=20
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev