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
|
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 968D1C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Oct 2022 04:35:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 60CF683E76
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Oct 2022 04:35:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 60CF683E76
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level:
X-Spam-Status: No, score=0.599 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, MONEY_NOHTML=2.499,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001]
autolearn=no 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 GnVPNONzKP_G
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Oct 2022 04:35:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2DC2283E69
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp1.osuosl.org (Postfix) with ESMTPS id 2DC2283E69
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Oct 2022 04:35:32 +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 1oipwM-0001o8-Lz; Thu, 13 Oct 2022 14:35:28 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 13 Oct 2022 14:35:22 +1000
Date: Thu, 13 Oct 2022 14:35:22 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Pieter Wuille <bitcoin-dev@wuille.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y0d/e2sEoNRgD7KP@erisian.com.au>
References: <Y0ZTtlRSBihNN9+v@erisian.com.au>
<0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net>
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: Thu, 13 Oct 2022 04:35:33 -0000
On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-dev wrote:
> In my view, it is just what I said: a step towards getting full RBF
> on the network, by allowing experimentation and socializing the notion
> that developers believe it is time.
We "believe it is time" for what exactly, though? (a) To start
deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or
18 months; or (b) to start switching mainnet mining and relay nodes over
to full RBF?
As far as experimentation goes, I don't really see this option as being
very likely to help: the default for this option is still false, so it's
likely going to be difficult to get non-opt-in RBF txs relayed or mined
anywhere, even on testnet or signet, no? (Maybe that's a difficulty that's
resolved by an addnode, but it's still a difficulty) If experimentation's
the goal, making the default be true for testnet/signet at least seems
like it would be pretty useful at least. Meaningful experimentation is
probably kind of difficult in the first place while fees are low and
there's often no backlog in the mempool, as well; something that perhaps
applies more to test nets than mainnet even.
If we're trying to socialise the idea that zeroconf deprecation is
happening and that your business now has a real deadline for migrating
away from accepting unconfirmed txs if the risk of being defrauded
concerns you, then enabling experimentation on test nets and not touching
mainnet until a later release seems fairly fine to me -- similar to
activating soft forks on test nets prior to activating it on mainnet.
> So I have a hard time imagining how it
> would change anything *immediately* on the network at large (without
> things like default on and/or preferential peering, ...), but I still
> believe it's an important step.
If we're instead trying to socialise the idea that relaying and mining
full RBF txs on mainnet should be starting now, then I think that's
exactly how this *would* change things almost immediately on the network
at large.
I think all it would take in practice to be able to repeatedly defraud
businesses accepting unconfirmed txs is perhaps 5% or 10% of blocks
to include full RBF txs [0] [1], and knowing some IP addresses to
addnode so that your txs relayed to those miners. And if core devs are
advocating that full RBF is ready now [2], and a patch to easily enable
it is included in a bitcoin core release, why wouldn't some small pools
start trying it out, leading to exactly that situation?
If most of the network doesn't relay your full-rbf txs, then that's
annoying for protocol developers who'd like to rely on it, but it's fine
for an attacker: it just means the business you're trying to trick has
less chance of noticing the attack before it's too late, because they'll
be less likely to see the conflicting tx via both their own node or
public explorers.
Cheers,
aj
[0] A few months ago, Peter Todd reported switching an OTS calendar to do
non-opt-in RBF, and didn't observe bumped txs being mined, which seems
to indicate there's not much hash power currently mining full RBF.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html
[1] Also why I remain surprised that accepting zeroconf is safe enough
in practice for anyone to do it. I suppose 5% of hashpower is perhaps
$100M+ investment in ASICs and $900k/day in revenue, and perhaps
all the current ways of enabling full RBF are considered too risky
to mess around with at that level.
[2] Antoine Riard's mail from June (that Peter's mail above was in reply
to) announced such a public node, and encouraged miners to start
adoption: "If you're a mining operator looking to increase your
income, you might be interested to experiment with full-rbf
as a policy." Presuming the IRC channel "##uafrbf" stands
for "user-activated full rbf", that also seems in line with
the goal being to socialise doing full RBF on mainnet immediately...
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html
|
