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
230
231
232
233
234
235
236
237
238
239
240
|
Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 875E0C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2022 23:46:01 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 4EE7740C28
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2022 23:46:01 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4EE7740C28
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=VADQc/ao
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id h9MjmIu9Uw1s
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2022 23:46:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2DC9240116
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com
[IPv6:2607:f8b0:4864:20::130])
by smtp2.osuosl.org (Postfix) with ESMTPS id 2DC9240116
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2022 23:46:00 +0000 (UTC)
Received: by mail-il1-x130.google.com with SMTP id h20so4398411ilj.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jun 2022 16:46:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=XLog6hV6QP6+R2zWDsP6HiHPSG/F7CLjLs7jEjy32Cs=;
b=VADQc/aoy8EsU+KqNfPaH3GsvBjaFkJvGHWWfWrNWb8VXOHjgr5a9S2n5b5rht5pMv
qUpZ8YgNaX+lwd7UVUT9yND/fiT56340FKk8mK8HSfHEaug/tpVmbNOzo5fOk7iicmXp
BIiGczGDrnENheJIywukfzVrYI6iKW1YpYjcjUJK1sElafi2YANIsK8UKMNzmu4/jiAV
obx2mz23cHxbqc2JgiSpy7Z4kygGKW22jFL5IKZfFOXy/pcH4SkhWEablnhdnqIomYb4
bNp/PdmrjgFAJigBK08cdrvMpmFO6zw8TQNK3vf55zgextsWyDhpiFr/p3EydUdkfsEY
976A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=XLog6hV6QP6+R2zWDsP6HiHPSG/F7CLjLs7jEjy32Cs=;
b=c6AHCG+TDAW1lDTykabsbKQUDWpQmx3csY40ExoUar7CwfTSDBexEn9U9y51X5iox4
yC9zgLYTAP34q/BsflsX4O2HjtaSrdD6wCKsINR1PbqS+N6uAGXrpbQIddy630QJoVkw
lh1uwBImbtDyJ+DjAzdjL6ZOJ06hhK1Er2HET4qNuDFR1hFroglFVtNlxRbkn82jB99p
m5+eZQ610SZ4LdSE2i8B5UJiNRCj7YSPm5W3VAMUcXD4SIfCGKIXGesz9NkgCJXJctCD
eSUZ82GrZKQ5a9K47ktO2YQf6tDES/vQ22vC68PkCUaSYPjwn/xFvc4UVCDLa88o1jPq
KgjQ==
X-Gm-Message-State: AJIora/sjTm1etNNgV3fidfXIqRPm5ELeDjAjLMJDFlXSXaSYlDqExV+
fAGufnrSFjgzBcOyPxbI/Wls3z3f347WFQqmBRr8ymT1b80=
X-Google-Smtp-Source: AGRyM1uQojwDy7Z/IwKB+Dz1KlZPyCmeh1l3NmCFggKEp6m6TUjEDHnw1ZChkDd12aWXmH9MQcpojio2v9lhyaf8JjQ=
X-Received: by 2002:a05:6e02:1b83:b0:2d9:2313:94c with SMTP id
h3-20020a056e021b8300b002d92313094cmr453423ili.191.1655855159274; Tue, 21 Jun
2022 16:45:59 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GOh-7weEypT9JrzcwthZJqHOfj7sf9FMuqi5_FZv0g7w@mail.gmail.com>
<YrEHo+3XLDNgIOnz@petertodd.org>
In-Reply-To: <YrEHo+3XLDNgIOnz@petertodd.org>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 21 Jun 2022 19:45:48 -0400
Message-ID: <CALZpt+EL=k_6iE5B950oz3EdLaQbRvgCNYZ8Lko4fcONcACvfw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="0000000000009173a605e1fdd229"
X-Mailman-Approved-At: Wed, 22 Jun 2022 00:02:05 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s
security
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 21 Jun 2022 23:46:01 -0000
--0000000000009173a605e1fdd229
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> BTW I changed one of my OTS calendars to issue fee-bumping txs without th=
e
> opt-in RBF flag set as an experiment. I also made sure txs would
propagate to
> the above node. As of right now, it's up to 32 replacements (once per
block),
> without any of them mined; the calendars use the strategy of starting at
the
> minimum possible fee, and bumping the fee up every time a new block
arrives
> without the tx getting mined. So that's evidence we don't have much
full-rbf
> hash power at this moment.
>
> You can see the current status at:
https://alice.btc.calendar.opentimestamps.org/
That's interesting. I'm not sure if we can conclude of the absence of
full-rbf hash power at this moment, as it could also be a lack of full-rbf
propagation path towards such potential hash power. I think the day we see
an opt-out replacement transaction mined, it would constitute a good hint
of full-rbf hash power (assuming the tx-relay topology stays relatively
stable across the transaction issuance...)
Anyway, if/when the `fullrbf` patch lands in Bitcoin Core, including
automatic outbound connections to few `NODE_REPLACE_BY_FEE` peers, I'm
thinking of reaching out to a few mining node operators to advocate them
with the new policy setting.
Antoine
Le lun. 20 juin 2022 =C3=A0 19:49, Peter Todd <pete@petertodd.org> a =C3=A9=
crit :
> On Mon, Jun 13, 2022 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev
> wrote:
> > For that reason, I believe it would be beneficial to the flourishing of
> > multi-party funded transactions to fix the Dos vector by seeing a subse=
t
> of
> > the network running full-rbf and enabling propagation of honest
> multi-party
> > transactions to the interested miners, replacing potential non-signalin=
g
> > double-spend from a malicious counterparty. Moving towards that
> direction,
> > I've submitted a small patch against Bitcoin Core enabling it to turn o=
n
> > full-rbf as a policy, still under review [3]. The default setting stays
> > **false**, i.e keeping opt-in RBF as a default replacement policy. I've
> > started to run the patch on a public node at 146.190.224.15.
>
> BTW I changed one of my OTS calendars to issue fee-bumping txs without th=
e
> opt-in RBF flag set as an experiment. I also made sure txs would propagat=
e
> to
> the above node. As of right now, it's up to 32 replacements (once per
> block),
> without any of them mined; the calendars use the strategy of starting at
> the
> minimum possible fee, and bumping the fee up every time a new block arriv=
es
> without the tx getting mined. So that's evidence we don't have much
> full-rbf
> hash power at this moment.
>
> You can see the current status at:
> https://alice.btc.calendar.opentimestamps.org/
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--0000000000009173a605e1fdd229
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> BTW I changed one of my OTS calendars to issue fee-bu=
mping txs without the<br>> opt-in RBF flag set as an experiment. I also =
made sure txs would propagate to<br>> the above node. As of right now, i=
t's up to 32 replacements (once per block),<br>> without any of them=
mined; the calendars use the strategy of starting at the<br>> minimum p=
ossible fee, and bumping the fee up every time a new block arrives<br>> =
without the tx getting mined. So that's evidence we don't have much=
full-rbf<br>> hash power at this moment.<br>> <br>> You can see t=
he current status at: <a href=3D"https://alice.btc.calendar.opentimestamps.=
org/">https://alice.btc.calendar.opentimestamps.org/</a><br><br>That's =
interesting. I'm not sure if we can conclude of the absence of full-rbf=
hash power at this moment, as it could also be a lack of full-rbf propagat=
ion path towards such potential hash power. I think the day we see an opt-o=
ut replacement transaction mined, it would constitute a good hint of full-r=
bf hash power (assuming the tx-relay topology stays relatively stable acros=
s the transaction issuance...)<br><br>Anyway, if/when the `fullrbf` patch l=
ands in Bitcoin Core, including automatic outbound connections to few `NODE=
_REPLACE_BY_FEE` peers, I'm thinking of reaching out to a few mining no=
de operators to advocate them with the new policy setting.<br><br>Antoine<b=
r></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">Le=C2=A0lun. 20 juin 2022 =C3=A0=C2=A019:49, Peter Todd <<a href=3D"ma=
ilto:pete@petertodd.org">pete@petertodd.org</a>> a =C3=A9crit=C2=A0:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jun 13, 202=
2 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev wrote:<br>
> For that reason, I believe it would be beneficial to the flourishing o=
f<br>
> multi-party funded transactions to fix the Dos vector by seeing a subs=
et of<br>
> the network running full-rbf and enabling propagation of honest multi-=
party<br>
> transactions to the interested miners, replacing potential non-signali=
ng<br>
> double-spend from a malicious counterparty. Moving towards that direct=
ion,<br>
> I've submitted a small patch against Bitcoin Core enabling it to t=
urn on<br>
> full-rbf as a policy, still under review [3]. The default setting stay=
s<br>
> **false**, i.e keeping opt-in RBF as a default replacement policy. I&#=
39;ve<br>
> started to run the patch on a public node at 146.190.224.15.<br>
<br>
BTW I changed one of my OTS calendars to issue fee-bumping txs without the<=
br>
opt-in RBF flag set as an experiment. I also made sure txs would propagate =
to<br>
the above node. As of right now, it's up to 32 replacements (once per b=
lock),<br>
without any of them mined; the calendars use the strategy of starting at th=
e<br>
minimum possible fee, and bumping the fee up every time a new block arrives=
<br>
without the tx getting mined. So that's evidence we don't have much=
full-rbf<br>
hash power at this moment.<br>
<br>
You can see the current status at: <a href=3D"https://alice.btc.calendar.op=
entimestamps.org/" rel=3D"noreferrer" target=3D"_blank">https://alice.btc.c=
alendar.opentimestamps.org/</a><br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>
--0000000000009173a605e1fdd229--
|
