summaryrefslogtreecommitdiff
path: root/35/4ec59edde49d7e90fa533d9d43af06fd3d01d4
blob: 88fb6088bf34b2655dcd056fde73f9c60ab1d932 (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
Return-Path: <aj@erisian.com.au>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4F544C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 Oct 2022 05:42:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 3120082779
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 Oct 2022 05:42:25 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3120082779
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
 UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id NeXJRHKkCESa
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 Oct 2022 05:42:24 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D053A81CDB
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
 by smtp1.osuosl.org (Postfix) with ESMTPS id D053A81CDB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 Oct 2022 05:42:23 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
 by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
 id 1oiUVW-0004JT-9p; Wed, 12 Oct 2022 15:42:19 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Wed, 12 Oct 2022 15:42:14 +1000
Date: Wed, 12 Oct 2022 15:42:14 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Dario Sneidermanis <dario@muun.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Pieter Wuille <bitcoin-dev@wuille.net>
Message-ID: <Y0ZTtlRSBihNN9+v@erisian.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <dM4QYbBYzzlSUgR4vscZ4juWcSYB_BfGztt4EdOHRGjC7tZXp0lvuP6ej29RCJSTEH9F9lH4rvapKEfVzvjXIyZRHzO5ag5RZWnLLayWIvo=@wuille.net>
 <CAKiPDnQzJBZ6cCRCFM7j01cNz=BcU_-_AcTh3jVo-Metpnek3w@mail.gmail.com>
X-Spam-Score-int: -18
X-Spam-Bar: -
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 05:42:25 -0000

On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev wrote:
> On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 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).
> It is not clear to me why you believe the merging of this particular pull request poses an immediate risk to you.

Did you see the rest of Dario's reply, bottom-posted after the quoted
text? Namely:

On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via bitcoin-dev wrote:
> 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).

That logic seems reasonably sound to me:

 - if adding the option does nothing, then there's no point adding it,
   and no harm in restricting it to test nets only

 - 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

(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 network
supports it, without needing to do an additional upgrade in the meantime;
but that seems like a pretty weak benefit)

Cheers,
aj