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
|
Return-Path: <bitcoin-dev@wuille.net>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 892B8C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Oct 2022 16:11:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 4FBEE410C0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Oct 2022 16:11:25 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4FBEE410C0
Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key,
unprotected) header.d=wuille.net header.i=@wuille.net header.a=rsa-sha256
header.s=protonmail3 header.b=ak8zxqNn
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id XNudvrLdRVKs
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Oct 2022 16:11:23 +0000 (UTC)
X-Greylist: delayed 23:52:57 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org F3F3C409FE
Received: from mail-4321.protonmail.ch (mail-4321.protonmail.ch [185.70.43.21])
by smtp4.osuosl.org (Postfix) with ESMTPS id F3F3C409FE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 12 Oct 2022 16:11:22 +0000 (UTC)
Date: Wed, 12 Oct 2022 16:11:05 +0000
Authentication-Results: mail-4321.protonmail.ch;
dkim=pass (2048-bit key) header.d=wuille.net header.i=@wuille.net
header.b="ak8zxqNn"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net;
s=protonmail3; t=1665591069; x=1665850269;
bh=58eYscuIZr3S6zYRY3jhajOC2sSSlCnbgxKZjH1PVvU=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID;
b=ak8zxqNnAKhhHe4bqu6UC67PeaZnsx4xe4al9a0aMBjGrWJBb0XTH5Qeh9UwP7Y9+
z5ISsLq6QjwjYEpBEz+UNmijuiZiO164aZjL8xGv7Sye+aTL+Lc6gZxLCYZbIMLcw7
JUPhSSbhapnb2Wv+nO/X/TP09Ee8iKNlPN+AT/nvWVVBfMq5ftt9kajzopV7xbi4Zg
Qw7xLN87QPep5IyXHTfkDQieHxmOI1Z/mKIl6HSfNBxDyw/3CojaAoLYRfkNIUpDmo
lJdK4ORyofgoFgTSqD/+Q8HqFBJVDJ4UQ7749LyIVTFkCrbUTB/DIC4yW6qHz6m6A7
rK9nzv61O7mnQ==
To: Anthony Towns <aj@erisian.com.au>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Message-ID: <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net>
In-Reply-To: <Y0ZTtlRSBihNN9+v@erisian.com.au>
References: <Y0ZTtlRSBihNN9+v@erisian.com.au>
Feedback-ID: 19463299:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 12 Oct 2022 17:51:40 +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: Wed, 12 Oct 2022 16:11:25 -0000
On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns <aj@erisian.com.=
au> wrote:
> On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev w=
rote:
>=20
> > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin=
-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> >=20
> > > Thanks for the fast answer! It seems I missed the link to the PR, sor=
ry for the
> > > confusion. I'm referring to the opt-in flag for full-RBF from #25353
> > > (https://github.com/bitcoin/bitcoin/pull/25353).
> > > It is not clear to me why you believe the merging of this particular =
pull request poses an immediate risk to you.
>=20
>=20
> Did you see the rest of Dario's reply, bottom-posted after the quoted
> text? Namely:
Oh, my mail client for some reason chose to hide all that. Dario, I'm sorry=
for missing this; I see now that you were certainly aware of what the PR u=
nder consideration did.
Further comments inline.
> On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via
> > The question then is whether an opt-in flag for full-RBF will have enou=
gh
> > 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 protoc=
ols
> > to assume that they can rely on full-RBF. If it is, then zero-conf appl=
ications
> > will be at severe risk (per the logic in the initial email).
>=20
>=20
> That logic seems reasonably sound to me:
>=20
> - if adding the option does nothing, then there's no point adding it,
> and no harm in restricting it to test nets only
>=20
> - if adding the option does do something, then businesses using zero-conf
> need to react immediately, or will go from approximately zero risk of
> losing funds, to substantial risk
>=20
> (I guess having the option today may allow you to manually switch your
> node over to supporting fullrbf in future when the majority of the networ=
k
> supports it, without needing to do an additional upgrade in the meantime;
> but that seems like a pretty weak benefit)
I certainly recognize that adding the flag is a likely step towards, over t=
ime, the full RBF policy becoming more widely adopted on the network. That =
is presumably the reason why people are in favor of having the flag, even d=
efault off - including me. I believe that policy's adoption is inevitable e=
ventually, but the speed at which that is achieved is certainly a function =
of availability and adopted of software which provides the option.
That said, I think it's a bit of a jump to conclude that the only two optio=
ns are that either the existence of the flag either has no effect at all, o=
r poses an immediate threat to those relying on its absence. In my view, it=
is just what I said: a step towards getting full RBF on the network, by al=
lowing experimentation and socializing the notion that developers believe i=
t is time. So I have a hard time imagining how it would change anything *im=
mediately* on the network at large (without things like default on and/or p=
referential peering, ...), but I still believe it's an important step.
Cheers,
--=20
Pieter
|
