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
|
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 2A6AD723
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Jun 2019 04:21:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f171.google.com (mail-it1-f171.google.com
[209.85.166.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 237A7174
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Jun 2019 04:21:30 +0000 (UTC)
Received: by mail-it1-f171.google.com with SMTP id i21so8550382ita.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 08 Jun 2019 21:21:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=OnCRByJYXa3+QAsPibJiTmHRr0Nwdy/eyPgbNVUgQJ0=;
b=qCoOZb+vETsPgKV7PeZIB7mBY3+jhJbudry3k/I+h+PRdfa+pIuKmhxY01HqjGsabK
uB/96AZTTeqxz/OTNttsJR4PgJjaYgTQMKCeVseXrKmculIPPjwNlPq0PLAseQlW7R4I
Vm4/deKBE30M7BAu6TXK4/ordvRXZIzCGf7eo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=OnCRByJYXa3+QAsPibJiTmHRr0Nwdy/eyPgbNVUgQJ0=;
b=h2uG71cYnoPqtof/o0wd0diIYh0fHxiOn8CdlTamksfzPl7/EYSCYDzyfyw9P5J303
zjNCOyBqYMF/UdvSmSEuXoavHraGX3R1Ihs4FHBHDRqjQ97rsN26Md2GXaOUPXS/wREu
iChoC70xA19YutFiOG+LTqk/RT461AZSQ/u+/rdk3g1IU5+Jema1TlNlGOFn4Ww0Ftu3
ed+/6tRrU2aDmyDVFHEdfH1IkHZ/mkERYH0G4sGi1xcDX3cMUnDlHeYaVUNegGqMNRwm
foKXdkfbXZ3Gn27arHocmoFpw1wZzgZbzAgmGBkJR2IFAyPb3jr8K7N+Mcxw6GRujGAx
I8aA==
X-Gm-Message-State: APjAAAUQaKvmWj/Qld+9rYd/7ZHwqnCdbm32Dd4lfKBahhBaLmdsF06p
E4Ab3Bw8KRzOZBOG1Rlplx8k0LmWxxiioKDUkEbrLtxwEfk=
X-Google-Smtp-Source: APXvYqyW/cc+h4eRa30tdv2qkuJIfVw5bHS5KjQxQdBBamTshgH0XKOpZUho43NV29szmp1wcx2av5vcoQLBFYtizcM=
X-Received: by 2002:a24:4344:: with SMTP id s65mr9496669itb.137.1560054090198;
Sat, 08 Jun 2019 21:21:30 -0700 (PDT)
MIME-Version: 1.0
References: <871s0c1tvg.fsf@rustcorp.com.au>
<CAMZUoKmXTONMqJ=0Vv7+e=q0CBL5h6Tio-5ec0bmZ+U4psOmCg@mail.gmail.com>
<87r287o1fh.fsf@rustcorp.com.au>
In-Reply-To: <87r287o1fh.fsf@rustcorp.com.au>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sun, 9 Jun 2019 00:21:19 -0400
Message-ID: <CAMZUoKmPAEYwCtiZ90cwiHz7C=WxaTouEy8dJwWC=Tkn5k-_PA@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Content-Type: multipart/alternative; boundary="000000000000e08eb0058adc65e5"
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
X-Mailman-Approved-At: Sun, 09 Jun 2019 08:18:41 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)
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: Sun, 09 Jun 2019 04:21:32 -0000
--000000000000e08eb0058adc65e5
Content-Type: text/plain; charset="UTF-8"
On Sat, Jun 8, 2019 at 11:59 PM Rusty Russell <rusty@rustcorp.com.au> wrote:
> "Russell O'Connor" <roconnor@blockstream.io> writes:
> > Hi Rusty,
> >
> > On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >> The new "emergency RBF" rule:
> >>
> >> 6. If the original transaction was not in the first 4,000,000 weight
> >> units of the fee-ordered mempool and the replacement transaction is,
> >> rules 3, 4 and 5 do not apply.
> >>
> >> This means:
> >>
> >> 3. This proposal does not open any significant new ability to RBF spam,
> >> since it can (usually) only be used once. IIUC bitcoind won't
> >> accept more that 100 descendents of an unconfirmed tx anyway.
> >>
> >
> > Is it not possible for Alice to grief Bob's node by alternating RBFing
> two
> > transactions, each one placing itself at the bottom of Bob's top
> 4,000,000
> > weight mempool which pushes the other one below the top 4,000,000 weight,
> > and then repeating with the other transaction? It might be possible to
> > amend this proposal to partially mitigate this.
>
> Good point. This will cost Alice approximately one tx every block, but
> that may still be annoying. My intuition says it's hard to play these
> games across swathes of non-direct peers, since mempools are in constant
> flux and propagation is a bit random.
>
> What mitigations were you thinking?
>
For example, "If the original transaction was not in the first 4,000,000
weight units of the fee-ordered mempool and the replacement transaction is
in the first 2,000,000 weight units...." might adequately address the issue.
There are probably other ways as well.
--000000000000e08eb0058adc65e5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jun 8, 2019 at 11:59 PM Rusty=
Russell <<a href=3D"mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au=
</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
"Russell O'Connor" <<a href=3D"mailto:roconnor@blockstream=
.io" target=3D"_blank">roconnor@blockstream.io</a>> writes:<br>
> Hi Rusty,<br>
><br>
> On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
><br>
>> The new "emergency RBF" rule:<br>
>><br>
>>=C2=A0 6. If the original transaction was not in the first 4,000,00=
0 weight<br>
>>=C2=A0 =C2=A0 =C2=A0units of the fee-ordered mempool and the replac=
ement transaction is,<br>
>>=C2=A0 =C2=A0 =C2=A0rules 3, 4 and 5 do not apply.<br>
>><br>
>> This means:<br>
>><br>
>> 3. This proposal does not open any significant new ability to RBF =
spam,<br>
>>=C2=A0 =C2=A0 since it can (usually) only be used once.=C2=A0 IIUC =
bitcoind won't<br>
>>=C2=A0 =C2=A0 accept more that 100 descendents of an unconfirmed tx=
anyway.<br>
>><br>
><br>
> Is it not possible for Alice to grief Bob's node by alternating RB=
Fing two<br>
> transactions, each one placing itself at the bottom of Bob's top 4=
,000,000<br>
> weight mempool which pushes the other one below the top 4,000,000 weig=
ht,<br>
> and then repeating with the other transaction?=C2=A0 It might be possi=
ble to<br>
> amend this proposal to partially mitigate this.<br>
<br>
Good point.=C2=A0 This will cost Alice approximately one tx every block, bu=
t<br>
that may still be annoying.=C2=A0 My intuition says it's hard to play t=
hese<br>
games across swathes of non-direct peers, since mempools are in constant<br=
>
flux and propagation is a bit random.<br>
<br>
What mitigations were you thinking?<br></blockquote><div><br></div><div>For=
example,=C2=A0 "If the original transaction was not in the first 4,00=
0,000 weight units of the fee-ordered mempool and the replacement transacti=
on is in the first 2,000,000 weight units...." might adequately addres=
s the issue.</div><div>There are probably other ways as well.</div></div></=
div>
--000000000000e08eb0058adc65e5--
|
