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
241
242
243
244
245
246
247
248
249
250
251
252
|
Return-Path: <dario@muun.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8D2EEC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Oct 2022 21:37:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 54B7560ADB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Oct 2022 21:37:53 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 54B7560ADB
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=muun-com.20210112.gappssmtp.com
header.i=@muun-com.20210112.gappssmtp.com header.a=rsa-sha256
header.s=20210112 header.b=QGF2gQYK
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
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 smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id h9u4UnIqppj6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Oct 2022 21:37:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C982F60AB9
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
[IPv6:2a00:1450:4864:20::336])
by smtp3.osuosl.org (Postfix) with ESMTPS id C982F60AB9
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Oct 2022 21:37:51 +0000 (UTC)
Received: by mail-wm1-x336.google.com with SMTP id o5so3612975wms.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Oct 2022 14:37:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=muun-com.20210112.gappssmtp.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=GR/d6el84e6/zzZs1WnR/MaPlAPAtIvQaCueeFcVgXc=;
b=QGF2gQYKMK2auNlZ1AT3XwpKS1S3hoxIvC0/bYdZ7ljwtoVUXzJpKLoa615RdKhUUr
bozfeMAZNU819JAqh/WsCIL4yUjf49GRz3iAjfDt+k3xmOY2/7y3PhIF/EKkM5996+UB
fQ7cLb2UyK9o+btQxxhbC43+o095DN7rM8Hxew95fnNkvyiqdnQ1QIutbw+tBAep33VU
VhI5cdD/yTLs4GHDFzrxz4+XMsvINAQhiBDUUy7nmI6B7vX+qScu4LdMUvRW0jQG33Ji
EAkgNa9svySLePG/ieEk+pmNMfoDP8KqJJubc+xniBrMCKQDGrLZheDffQYicUzTpucb
sHjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=GR/d6el84e6/zzZs1WnR/MaPlAPAtIvQaCueeFcVgXc=;
b=RjTZaxPLq962rt6HCXM85HwTJmhw9C9vXMrv3hwfWvFGo+IBSNyn4sL0t5vn05IiHS
PCsXhIJkXdrRVIwAaHFZAMVC5HS3dNbmY/0BpO8NAb6rSeyoazjaqgozUw6ASoykkfP7
l4lk80o428MWTPO7Ym7WgzHY/fba3luQzodZlXLKeJ0+DeiEwLG6Jvs0eZf386MuIvl3
lEIrWjVNfXhVet7JkU08q/9YGRpop0KBSDgsORR1soMGampWnG432xB9ZfyE5bWR9xsh
3uWOUQdC0XNxLoF1KqY3hnzLrQ02KrN9Kvke3n4h911EURcpPcORyQ3aZGYkoneTjsOo
Gfqg==
X-Gm-Message-State: ACrzQf3nzIoyAU1oPuPZ3dLmsoVWKmYd/uZROnE2E8mltbjxgHv1Idqh
ODH6B8pv/ZKt4MttOnMQ3l1sIJ7Hve0+HTEdIGd+xrAcZv9scA==
X-Google-Smtp-Source: AMsMyM7gvNli1jkLnBjqHxvtTy8vOO5vldVm2Ok9zven+NPe0ZLcId8LXmhv+J0q1mDPRmLWLEzy51mqIOXRWmefrBE=
X-Received: by 2002:a05:600c:3582:b0:3c2:7002:2cb0 with SMTP id
p2-20020a05600c358200b003c270022cb0mr4578619wmq.170.1665178669900; Fri, 07
Oct 2022 14:37:49 -0700 (PDT)
MIME-Version: 1.0
References: <CAKiPDnTPyduCm2Db0v51m_hbCSGbZcUcCwg9=hwJGKeiFeTWBg@mail.gmail.com>
<1ee5a4e7ecffa0f638bbd45b195ecca6@dtrt.org>
In-Reply-To: <1ee5a4e7ecffa0f638bbd45b195ecca6@dtrt.org>
From: Dario Sneidermanis <dario@muun.com>
Date: Fri, 7 Oct 2022 18:37:38 -0300
Message-ID: <CAKiPDnQzJBZ6cCRCFM7j01cNz=BcU_-_AcTh3jVo-Metpnek3w@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="0000000000001b825305ea789f0f"
X-Mailman-Approved-At: Fri, 07 Oct 2022 21:45:22 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
danger
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: Fri, 07 Oct 2022 21:37:53 -0000
--0000000000001b825305ea789f0f
Content-Type: text/plain; charset="UTF-8"
Hello David,
Thanks for the fast answer! It seems I missed the link to the PR, sorry for
the
confusion. I'm referring to the opt-in flag for full-RBF from #25353
(https://github.com/bitcoin/bitcoin/pull/25353).
On Fri, Oct 7, 2022 at 2:21 PM David A. Harding <dave@dtrt.org> wrote:
> On 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:
> > Hello list,
> >
> > I'm Dario, from Muun wallet [...] we've been reviewing the latest
> > bitcoin core release
> > candidate [...] we understood we had at least a year from the initial
> > opt-in deployment until opt-out was deployed, giving us enough time to
> > adapt
> > Muun to the new policies. However, when reviewing the 24.0 release
> > candidate
> > just a few days ago, we realized that zero-conf apps (like Muun) must
> > *immediately turn off* their zero-conf features.
>
> Hi Dario,
>
> I'm wondering if there's been some confusion. There are two RBF-related
> items in the current release notes draft:[1]
>
> 1. "A new mempoolfullrbf option has been added, which enables the
> mempool to accept transaction replacement without enforcing BIP125
> replaceability signaling. (#25353)"
>
> 2. "The -walletrbf startup option will now default to true. The wallet
> will now default to opt-in RBF on transactions that it creates.
> (#25610)"
>
> The first item (from PR #25353) does allow a transaction without a
> BIP125 signal to be replaced, but this configuration option is set to
> disabled by default.[2] There have been software forks of Bitcoin Core
> since at least 2015 which have allowed replacement of non-signaling
> transactions, so this option just makes that behavior a little bit more
> accessible to users of Bitcoin Core.
The "activation" of full-RBF after deployment works in a pretty interesting
way:
1. If no miner is running full-RBF or there aren't easily accessible
connected
components of nodes running full-RBF connected to the miners, then
full-RBF
is mostly ineffective since replacements aren't relayed and/or mined.
2. There's a middle ground where *some* connected components of full-RBF
nodes
can relay and mine replacements, where some full-RBF nodes will be able
to
replace via full-RBF and some won't (depending on their peers).
3. With high enough adoption, the relay graph has enough density of full-RBF
nodes that almost all full-RBF nodes can replace transactions via
full-RBF.
While there have been forks of Bitcoin Core (like Bitcoin Knots) running
full-RBF for a while, today most nodes (by far) are running Bitcoin Core.
So,
Bitcoin Core adding an opt-in flag (ie. off by default) makes it easier to
be
picked up by most node operators. Making the flag opt-out (ie. on by
default)
would make it easier still. We are dealing with a gradient going from hard
enough that we are still in 1, to easy enough that we get to 3.
The question then is whether an opt-in flag for full-RBF will have enough
adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
objective of allowing nodes participating in multi-party funding protocols
to
assume that they can rely on full-RBF. If it is, then zero-conf applications
will be at severe risk (per the logic in the initial email).
--0000000000001b825305ea789f0f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">Hello David,<br><br>Thanks for the fast a=
nswer! It seems I missed the link to the PR,=C2=A0sorry for the</div><div d=
ir=3D"ltr">confusion. I'm referring to the opt-in flag for full-RBF fro=
m #25353<br>(<a href=3D"https://github.com/bitcoin/bitcoin/pull/25353">http=
s://github.com/bitcoin/bitcoin/pull/25353</a>).<br></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 7, 2022 at 2=
:21 PM David A. Harding <<a href=3D"mailto:dave@dtrt.org">dave@dtrt.org<=
/a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">O=
n 2022-10-07 06:20, Dario Sneidermanis via bitcoin-dev wrote:<br>
> Hello list,<br>
> <br>
> I'm Dario, from Muun wallet [...] we've been reviewing the lat=
est <br>
> bitcoin core release<br>
> candidate [...] we understood we had at least a year from the initial<=
br>
> opt-in=C2=A0 deployment until opt-out was deployed, giving us enough t=
ime to <br>
> adapt<br>
> Muun to the new policies. However, when reviewing the 24.0 release <br=
>
> candidate<br>
> just a few=C2=A0 days ago, we realized that zero-conf apps (like Muun)=
must<br>
> *immediately turn off* their zero-conf features.<br>
<br>
Hi Dario,<br>
<br>
I'm wondering if there's been some confusion.=C2=A0 There are two R=
BF-related <br>
items in the current release notes draft:[1]<br>
<br>
1. "A new mempoolfullrbf option has been added, which enables the <br>
mempool to accept transaction replacement without enforcing BIP125 <br>
replaceability signaling. (#25353)"<br>
<br>
2. "The -walletrbf startup option will now default to true. The wallet=
<br>
will now default to opt-in RBF on transactions that it creates. <br>
(#25610)"<br>
<br>
The first item (from PR #25353) does allow a transaction without a <br>
BIP125 signal to be replaced, but this configuration option is set to <br>
disabled by default.[2]=C2=A0 There have been software forks of Bitcoin Cor=
e <br>
since at least 2015 which have allowed replacement of non-signaling <br>
transactions, so this option just makes that behavior a little bit more <br=
>
accessible to users of Bitcoin Core.</blockquote><div><br></div>The "a=
ctivation" of full-RBF after deployment works in a pretty interesting =
way:<br><br>1. If no miner is running full-RBF or there aren't easily a=
ccessible connected<br>=C2=A0 =C2=A0components of nodes running full-RBF co=
nnected to the miners, then full-RBF<br>=C2=A0 =C2=A0is mostly ineffective =
since replacements aren't relayed and/or mined.<br>2. There's a mid=
dle ground where *some* connected components of full-RBF nodes<br>=C2=A0 =
=C2=A0can relay and mine replacements, where some full-RBF nodes will be ab=
le to<br>=C2=A0 =C2=A0replace via full-RBF and some won't (depending on=
their peers).<br>3. With high enough adoption, the relay graph has enough =
density of full-RBF<br>=C2=A0 =C2=A0nodes that almost all full-RBF nodes ca=
n replace transactions via full-RBF.<br><br>While there have been forks of =
Bitcoin Core (like Bitcoin Knots) running<br>full-RBF for a while, today mo=
st nodes (by far) are running Bitcoin Core. So,<br>Bitcoin Core adding an o=
pt-in flag (ie. off by default) makes it easier to be<br>picked up by most =
node operators. Making the flag opt-out (ie. on by default)<br>would make i=
t easier still. We are dealing with a gradient going from hard<br>enough th=
at we are still in 1, to easy enough that we get to 3.<br><br>The question =
then is whether an opt-in flag for full-RBF will have enough<br>adoption to=
get us from 1 to 2. If it isn't, then #25353 won't meet its<br>obj=
ective of allowing nodes participating in multi-party funding protocols to<=
br>assume that they can rely on full-RBF. If it is, then zero-conf applicat=
ions<br><div>will be at severe risk (per the logic in the initial email).</=
div><div><br></div></div></div>
--0000000000001b825305ea789f0f--
|
